Handout For Print Share Point Server 2010

Microsoft SharePoint Server 2010
1/4/2010 Microsoft Corporation Rohit Sharma PFE Contents TOC New Feature & Improvements Surveys Content Type Record Center Indexing Workflows SPD Workflow Three State Workflow Approval workflow Upgrade From MOSS to SPS 2010 Patch Management Security S.No 0 1 2 3 4 5 6 7 8 9 10 11 12
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 multilingual 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 1
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
Page 2
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 users 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
Page 3
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, multistage dispositions, in-place records and e-discovery.
Page 4
Search
As discussed in my first post, enterprise search is a big investment area for Microsoft from Search Server Express to SharePoints 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.
Page 5
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 peoples 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 valueadded 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.
Page 6
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.
Page 7
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.
Page 8
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.
Page 9
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.
Page 10
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.
Page 11
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 isnt a supported configuration for production, we heard you that you want to use it as a development environment.
Page 12
Feature Name / Area Sites Office Integration Line-of-Business Integration Read/Write capabilities Enterprise Management Operations Management tools and reporting Web Analytics Mobile Connectivity Full-fidelity viewing Editing to mobile Office Interaction Read/Write capabilities Robust User Experience Contextual Ribbon Microsoft Silverlight Office Web Applications Tagging Audience Targeting Communities People profiles Photos and presence Microblogging Ask Me About Note Board
SharePoint Server 2007
SharePoint Server 2010
Included Included
Improved Improved New
Included Included
Improved Improved New
Included
Improved New New
Included Included Included
Improved Improved Improved New New New New New
Included
Improved New New New New
Page 13
Recent activities Organization Browser Add colleagues Social bookmarks Tags Tag clouds Tag profiles Blogs Wikis Enterprise wikis Ratings Colleague suggestions Keyword suggestions Content Compliance Everywhere Flexible Records Management Shared Content Types and Managed Metadata Service Content Organizer Rich Media Management Document Sets Word Automation Services Support for Accessibility Standards Search People and expertise search Included Included Included Included Included
New New Improved New New New New Improved Improved New New Improved New
New New
New New New New New New
Improved
Page 14
Search from Windows 7 and Windows Mobile Common connector framework for indexing and federation Scale and performance via improved topology architecture Ability to build search-powered applications Refinement panel and sorting Search in context Social behavior improves relevance Thumbnails, previews, and view in browser Advanced content processing with strong linguistics Insights KPI details Dashboard Designer Enhanced navigation, including filtering and sorting (top/bottom 10, switchable measures) Publish more workbooks JavaScript Object Model PowerShell scripting Richer fidelity with Excel workbooks Support for Analytical Services formatting Additional data sources, including external lists and "PowerPivot" workbooks (naming to come) Improved strategy map connection and formatting Seamless management of dashboard content
Included
Improved
Included
Improved
Included
Improved
Included
Improved New New New
New
New
New Included Improved
New New New New
New
New
New
New
Included
Improved
Page 15
Integrated filter framework Calculated KPIs Improved visualizations Chart Web Parts Business Intelligence Center Composites Browser-based customizations Business Connectivity Services SharePoint Designer Human workflows Forms Services Visio Services Access Services Sandboxed Solutions Included Included Included Included
New New New New New
Improved New Improved Improved Improved New New 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 Service Description A set of binaries installed on the server farm which
Page 16
are capable of some functionality. Service Application The Service described above but configured for a specific SharePoint farm. The Proxy service is really a pointer to a Service Application within the farm that exists on the Web front-end. The instance of the Service Application running on the application Server. 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.
Service Application Proxy
Service Instance
Service Consumer
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 SSPs in the farm, each has its own set of Services and applications. In this SharePoint 2007 environment you cant share services between SSPs 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 17
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 Users and Profiles (People related applications) Metadata Services Business Connectivity Services (BCS) Search Services Secure Store Services Web Analytics Services Services that cannot be published Usage and Health Services Site Services Project Services Excel Calculation Services Access Web 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 18
probably not a major issue. Now, the overall concept of the new SharePoint Services architecture is now clear, lets 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).
Page 19
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:
Page 20
IIS 7.5 SharePoint Web Services list Now a big minus we only see a long GUID that isnt 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).
Page 21
SharePoint 2010 Search - Whats 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. Page 22
Figure 1 shows a sample deployment with a partitioned and mirrored search index, multiple property databases, multiple crawlers and multiple crawl databases.
Page 23
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. Page 24
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
Page 25
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
Page 26
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
Page 27
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
Page 28
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:
Page 29
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.:
Page 30
Create Content Organizer rules

I added rules by selecting: Site Settings / Site Settings / Site Administration / Content Organizer Rules:
What happens if my target library doesnt 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
Page 31
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.
Page 32
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.
Page 33
Its 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 youre overriding the retention schedule at the Content Type level:
Page 34
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:
Page 35
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:
Page 36
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.
Page 37
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 surveys questions using the
Page 38
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.
Page 39
As we can see this is a really simple and useful feature to manage the content of the surveys in Sharepoint Foundation.
Page 40
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. 2. 3. 4. 5. 6. 7. To start Visual Studio 2010, click the Start Menu, click All Programs, click Microsoft Visual Studio 2010, and then click Microsoft Visual Studio 2010. On the File menu, point to New, and then click Project. In the New Project dialog window, in the Installed Templates section, click Visual C#, click SharePoint, and then click 2010. Select Empty SharePoint Project from the project items. In the Name box, type Create ContentType and then click OK. In the SharePoint Customization Wizard, type the local Web site that you want to use for this exercise (such as http://localhost/SampleWebSite). 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
Page 41
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.
Page 42
4. Click on New External Content Type
5. You will get a screen as shown below Click on Add Connection
Page 43
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
Page 44
10. From the next screen you have to select the columns you want to display
Page 45
11. If successfully added you will get a screen like below 12. Click on Create Profile Page
Page 46
Page 47
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
Page 48
3. Click OK 4. Select the options as shown below
Page 49
Page 50
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
Page 51
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 52
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 sites 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 sites 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 53
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 doesnt 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
Page 54
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
Page 55
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
Page 56
6. By Default it will take the Choice column you created
7. You can write custom email messages as shown below
Page 57
Page 58
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
Page 59
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
Page 60
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
Page 61
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, lets 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.
Page 62
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.
Page 63
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
Page 64
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, its Approvers HR Docs), but it could be any group you wish. Click the
Page 65
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
Page 66
Demo Default WorkflowsApproval

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.
Page 67
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.
Page 68
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.
Page 69
As the workflow name indicates the task is complete when the document is approved or rejected.
Page 70
Upgrade
Page 71
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 WorkflowsApproval ..............................................................................................................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
Page 72
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 Whats 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
Page 73
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
Page 74
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.
Page 75
Section 1: Overview of SharePoint 2010 Upgrade
Section 1: Overview and Whats New
Whats New, Whats Changed, Whats Gone, Whats Not Supported Pre-upgrade Checker PowerShell Upgrade Commands
3
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.
Page 76
Changes and Improvements to the Upgrade Process in SharePoint 2010
Whats New, Whats Changed, Whats Gone, Whats Not Supported

Whats New

Whats Gone
Upgrade preparation tools Gradual upgrade PowerShell upgrade cmdlets Side-by-side installation Visual Upgrade Whats Not Supported Parallel Upgrade Pipelines Upgrade from a farm running earlier than WSS v3 SP2 Whats Changed Additional Upgrade methods Direct upgrade from WSS v2/SPS 2003 Improved Upgrade status logging and reporting Improved Read-only database support
4
SharePoint 2010 offers several new and changed items that can affect the upgrade process. Whats 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 content databases at the same time. by upgrading multiple
Whats 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
Whats gone The following upgrade features have been completely removed from SharePoint 2010: Gradual upgrade Page 77
Side-by-side installation
Whats 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.
Page 78
Pre-Upgrade Check
Pre-Upgrade Check
In WSS/MOSS SP2: stsadm o preupgradecheck
5
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 79
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 ServerInfo FarmInfo UpgradeType SiteTemplates Features LanguagePacks AAMURLs Description Specifies all servers that are running SharePoint bits in the farm Specifies the components of this farm Local server or Severity farm Local Farm Information Information Information Information Information Information Information
Specifies the upgrade types supported by the Local farm Specifies that the farm uses the following site Local definitions Specifies the features installed on the farm Local
Specifies the language packs required for the Local farm Specifies the AAM URLs within the current environment that need to be considered when upgrading Local
OSType
Specifies that this server machine in the farm Local does not have the 64-bit edition of Windows Server 2008 or later installed Specifies that the content databases are modified by user, and cannot be upgraded Specifies that content databases contain orphans Specifies that some sites cannot be referenced properly Farm Farm Farm Farm Local Local Local
Error
DatabaseSchema DataOrphan SiteOrphan
Error Error Error Error Error Error Error Error
UnfinishedGradualUpgra Specifies that this farm is currently being de upgraded via the gradual upgrade process MissingWebConfig InvalidHostNames InvalidServiceAccount DatabaseReadOnly Specifies that this Web site does not have a web.config file Specifies that invalid host names are found Specifies that the application pool account must be fixed
Specifies that the databases in this farm are Farm configured as read-only and the upgrade will fail unless they are configured as read-write Specifies that the databases in this farm are hosted on the Windows Internal Database; Farm
WYukonLargeDatabase
Error
Page 80
Name
Description 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.
Local server or Severity farm
WYukonLargeSiteCollecti Specifies that the site collections in this farm Farm on are hosted on the Windows Internal Database and are larger than 4 GBs
Error
Note: The rule file is located in the %commonprogramfiles%/Microsoft Shared/web server extensions/12/config/preupgradecheck.
Page 81
Pre-Upgrade Check Output
Pre-Upgrade Check output
6
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 preupgrade 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.
Page 82
PowerShell Upgrade Commands
PowerShell Upgrade Commands
Mount-SPContentDatabase Upgrade-SPContentDatabase
7
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 MountSPContentDatabase 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.
Page 83
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
Page 84
Improved Upgrade Logging
Improved Upgrade Logging
New Logging Features

Unique log is created per upgrade Log files in the ULS logging directory
8
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.
Page 85
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.
Page 86
Section 2: Upgrade Methodology
Section 2: Upgrade Methodology
Learn Plan/Prepare Test Implement Validate
10
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.
Page 87
Learn
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
11
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 32bit hardware. If you start in 32-bit, you must first migrate to 64-bit hardware. Microsoft Corporation Page 88
Page 89
Pre-Upgrade Steps
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
12
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.
Page 90
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
Page 91
-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>
Page 92
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:
Page 93
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.
Page 94
In-Place Upgrade
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.
14
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.
Page 95
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.
Page 96
Database Attach Upgrade
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 Farm-wide settings not transferred Customizations must be manually installed Need direct access to the database servers Time consuming
Disadvantages
15
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) Page 97
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.
Page 98
Hybrid Upgrade
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.
16
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.
Page 99
Test the Upgrade
Test the upgrade

Build test farms Test the upgrade approach Test-SPContentDatabase
17
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? Page 100
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 preupgrade 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 101
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:
Page 102
Section 2 Review
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?
18
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?
Page 103
Section 3: Performing the Upgrade
Section 3: Performing the Upgrade
In-Place Database Attach Hybrid read-only database Hybrid detached content databases
20
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.
Page 104
Performing an In-Place Upgrade
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
21
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.
Page 105
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/enus/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.
Page 106
Performing a Database Attach Upgrade
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
22
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.
Page 107
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.
Page 108
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
Page 109
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.
Page 110
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.
Page 111
Performing a Database Attach Upgrade (continued)
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.
23
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.
Page 112
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.
Page 113
Validating the Upgrade
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.
24
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).
Page 114
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-YYYYMMDDHHMMSS-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.
Page 115
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
Page 116
Section 4: Upgrade Considerations
Section 4: Upgrade Considerations
Upgrade SSPs to Service Applications Downtime mitigation processes Visual Upgrade
26
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.
Page 117
Upgrading SSPs to Service Applications with PowerShell
Upgrade the SSP to Service Applications
Can be done through PowerShell Upgrade-SPEnterpriseSearchServiceApplication Upgrade-SPSingleSignOnDatabase Upgrade-SPProjectWebInstance
27
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.
Page 118
Methods to Mitigate Upgrade Downtime
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)
28
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 119
Note: For more information, refer to the Roadmap for in-place upgrade with detached databases (SharePoint Server 2010) topic at http://technet.microsoft.com/enus/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/enus/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
Page 120
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.
Page 121
Visual Upgrade
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
29
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.
Page 122
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.
Page 123
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:
Page 124
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:
Page 125
Page 126
Section 4 Review
Section 4 Review
How can you upgrade your SSP to Service Applications? Why would you want to preview the Visual Upgrade?
30
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?
Page 127
General Administration and Service Applications
Page 128
Page 129
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.
Page 130
Section 1: Central Administration
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
3
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.
Page 131
Central Administration Home Page
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
4
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
Page 132
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:
Page 133
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.
Page 134
Central Administration Ribbon Menu
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 madeknown as contextual menu
6
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.
Page 135
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.
Page 136
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.
Page 137
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. Page 138
Example:
<URL> is the public URL for the Web application.
New-SPWebApplication -Name "Contoso Internet Site" -ApplicationPool "ContosoAppPool" ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe") -Port 80 URL "http://www.contoso.com"
Page 139
Lab 2A: Creating a Web Application
Page 140
Site Collections
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
14
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 toplevel 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 NewSPSite 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.
Page 141
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.
Page 142
Creating New Site Collections
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
15
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 Page 143
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.
Page 144
Section 1 Review
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?
18
Answer the questions listed on the slide above.
Page 145
Section 2: Timer Jobs
Section 2: Timer Jobs
Changed Timer Job Features Improved Timer Job Features Preferred Timer Server
19
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.
Page 146
Changed Timer Job Features
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
20
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 Page 147
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 Page 148
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.
Page 149
Page 150
Improved Timer Job Features
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
22
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 longrunning 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.
Page 151
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-timerlocks). 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.
Page 152
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.
Page 153
Preferred Timer Server
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
24
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. Page 154
Surplus locks. Specify locks that should be owned by another server (preferred or nonpreferred 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 nonexpired 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.
Page 155
Page 156
Section 2 Review
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?
26
Answer the questions listed on the slide above.
Page 157
Section 3: Service Applications
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
27
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.
Page 158
SSPs vs. Service Applications
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
28
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.
Page 159
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 Page 160
State Service Visio Graphics Service User Profile Service
Page 161
Service Application Flexibility
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
29
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.
Page 162
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.
Page 163
Service Application Model
Service Application Model
Consists of:
Service Service machine instance Service application Service consumer Service database WCF Web service Application directories
30
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.
Page 164
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 codea Web Part, a Windows PowerShell cmdlet, or another Web servicethat 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.
Page 165
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.
Page 166
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\
Page 167

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
32
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 Microsoft Corporation Page 168
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).
Page 169
Creating Service Applications
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
34
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.
Page 170
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.
Page 171
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.
Page 172
Managing Service Applications
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
37
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:
Page 173
Page 174
Page 175
Classes of Service Application Administrators
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
40
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.
Page 176
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.
Page 177
Connecting Web Applications to Service Applications
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
42
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.
Page 178
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:
Page 179
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[]>]
Page 180
Customizing Service Application Proxy Groups
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.
44
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.
Page 181
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:
Page 182
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.
Page 183
Publishing and Connecting to a Service between Farms
Publishing and Connecting to a Service between Farms

Service applications can be consumed individually within or across farms. To share services across farms:
1.
2. 3. 4.
Exchange trust certificates between the publishing and consuming farms. On the publishing farm, publish the service application. On the consuming farm, connect to the remote service application. 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.
47
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 Microsoft Corporation Page 184
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
Page 185
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.
Page 186
Section 3 Review
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?
49
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.
Page 187
Module 2 Summary
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.
50
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.
Page 188
Module Patch Management
Page 189
Page 190
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.
Page 191
Section 1: Patching Overview
Section 1: Patching Overview
Whats Inside A Patch? Types of Updates Service Pack and Cumulative Update Interaction Overview of Patching Process Upgrade Approach In Place Upgrade Approach - DBAttach
3
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.
Page 192
Whats Inside a Patch?
Whats 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
4
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 packagesometimes called a patchis 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:
Page 193
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 installedfor 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.
Page 194
Types of Updates
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 Includes all of the latest global and localized updates
o o o
Includes all updates since RTM Does not include Fast Search for SharePoint or Office Web Applications components updates.
5
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 postPage 195
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.
Page 196
Types of Updates (Continued)
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
6
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.
Page 197
Service Pack and Cumulative Update Interaction
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 serverpackages 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.
7
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 filesthose 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.
Page 198
Overview of the Patching Process
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
9
It is important to understand that deploying patches in a SharePoint Server 2010 environment is a twophase processupdating 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 199
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 phaseIn-Place and DBAttach.
Page 200
Upgrade Approach: In-Place
Upgrade Approach In-Place
All farm components (SharePoint processes and SharePoint databases) are upgraded sequentially. Uses PSConfig
Command-line tool Graphical User Interface
10
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.
Page 201
Upgrade Approach: DBAttach
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
11
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.
Page 202
Note: You can attach content databases to a SharePoint farm by using the MountSPContentDatabase Windows Powershell cmdlet.
Page 203
Section 1 Review
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?
12
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?
Page 204
Section 2: Improvements in Patching From Previous Version
Section 2: Improvements In Patching From Previous Version

Backwards Compatibility Performance improvements PSConfig Improvements Monitoring the status of updates
13
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.
Page 205
Backwards Compatibility
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
14
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
Page 206
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.
Page 207
Backwards Compatibility (Continued)
Backwards Compatibility (continued)

Shouldnt 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
15
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 UpgradeSPContentDatabase Windows PowerShell command.
Page 208
Performance Improvements
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 Parallel upgrading multiple databases on separate spindles should be much quicker than serially upgrading them
But dont expect it to be as fast as the time it takes to upgrade your largest database on its own
Parallelism has benefits and limits

o
16
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 209
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.
Page 210
PSConfig Improvements
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
17
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.
Page 211
Page 212
Monitoring the Status of Updates
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
19
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 locationthe Check Product and Patch Installation status pagewhere 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 213
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
Page 214
Section 2 Review
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?
20
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.
Page 215
Section 3: Patching Process
Section 3: Patching Process
Patching Strategy Preparation Minimizing Downtime Upgrade Order and Parent-Child Farms Verifying Success Common Failures
21
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.
Page 216
Patching Strategy
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
22
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.
Page 217
The Preparation Phase
Preparation
Plan the patch deployment strategy Create a communication plan Back up the environment Document the environment Test
23
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
Page 218
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.
Page 219
Minimizing Downtime Using Parallel Database Upgrade
Minimizing Downtime
Parallel database upgrade with multiple threads Parallel database upgrade using multiple farms
24
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 220
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.
Page 221
Minimizing Downtime Using Read-Only Databases
Minimizing Downtime (continued)

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
25
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 222
68. Switch routing or DNS back to the original fully upgraded farm.
Page 223
Upgrade Order and Parent-Child Farms
Upgrade Order and Parent-Child Farms

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
26
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
Page 224
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.
Page 225
Verifying Patch Installation Success
Verifying Success
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
27
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.
Page 226
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 upgradewhen the files are being copiedthe SQL Server schema is upgraded only after the PSConfig tool is run.
Page 227
Common Patch Installation Issues
Common Failures
Data issues
Connectivity to data sources
Orphaned sites or lists Hidden column data
Lack of space Patch installation not recognized

Get-SPProduct -local
28
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 spacefor example, for transaction log files on your database serversupgrade 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 228
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
Page 229
Section 3 Review
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?
29
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?
Page 230
Module Summary
Module Summary
Patching Overview Improvements In Patching From Previous Version Patching Process
30
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.
Page 231

Handout For Print Share Point Server 2010

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Handout For Print Share Point Server 2010

Transféré par

Droits d'auteur :

Formats disponibles

Microsoft SharePoint Server 2010

NEW FEATURES SPS 2010

SharePoint Server 2007

SharePoint Server 2010

Improved Improved New

Improved Improved New

Improved New New

Included Included Included

Improved Improved Improved New New New New New

Improved New New New New

New New New New New New

Improved New New New

New Included Improved

New New New New

New New New New New

Improved New Improved Improved Improved New New New

SharePoint 2010 Service Applications Architecture (SSA)

Service Application Proxy

Table representing new core-service definitions

Visio graphics Service Application setup window

SharePoint 2010 Search - Whats next for IT-Pros

Figure 1: Sample SharePoint 2010 Search deployment.

Figure 3: Report on crawl-rate over time

To list all SharePoint 2010 Cmdlets, type:

To view the usage of a Cmdlet, type:

To view the detailed usage of a Cmdlet, type:

Create a Records Center

The new look of the SharePoint 2010 Records Center:

Create / enable Content Types

Create libraries for storing Records

Create Content Organizer rules

Retention schedule using Content Types

Retention schedule using Library/folder

In-Place Records Management

Creating a Survey in SPS 2010

add Questions option in the Settings menu

Content Type in MOSS

Create a SharePoint 2010 Project

To create the SharePoint project

Create a Content Type

To create a content type

3. Click on External Content Type.

4. Click on New External Content Type

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

13. You are done with External Content Type creation

3. Click OK 4. Select the options as shown below

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

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

7. You can write custom email messages as shown below

Demo SPD Workflow

Click Create Group in the ribbon

Fill out the form Click the Create button

Add the desired users to your new group

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

10. Select Send an email for this action.

11. Your screen should look like this:

Click these users

12. See this screen:

Demo Default WorkflowsApproval

Section 1: Overview of SharePoint 2010 Upgrade

Section 1: Overview and Whats New

Changes and Improvements to the Upgrade Process in SharePoint 2010