Chapter 2

Planning and Deploying a SharePoint 2010 Installation and Upgrade

Microsoft Exam Objective Covered in This Chapter:

• Installing and Configuring a SharePoint Environment
  • Deploy new installations and upgrades

Deploying SharePoint Server 2010 into your production environment can take several different paths depending on your current situation. If you administer a Microsoft Office SharePoint Server 2007 (MOSS 2007) infrastructure, you will be planning an upgrade strategy. If you are deploying SharePoint Server 2010 as a first-time installation, your planning process will be very different. You also need to consider the scope of the deployment. You may be installing SharePoint as a single-server solution with an integrated database or deploying SharePoint in a server farm with database services provided by SQL Server 2005 or 2008.

Regardless of your goals, you have to start with a plan. Particularly when studying for a certification exam, there is a tendency to want to immediately launch into installing the server and application software on a server or workstation machine and get down to business. This chapter will start by presenting how to plan for different SharePoint Server 2010 architectures and then proceed to the installation and deployment of both new and upgrade SharePoint environments.

Planning the SharePoint Server 2010 Environment

In Chapter 1, “What’s New in Microsoft SharePoint 2010,” you learned there’s a great deal of preparation to be done, particularly in terms of your hardware and software platforms, prior to installing SharePoint Server 2010. You must make sure you have 64-bit hardware and that all your server and database software is 64-bit. However, even when you have met the basic requirements, you still need to plan for an installation or upgrade deployment based on your architecture and business requirements. Since your architecture design will follow your business needs as well as technical and structural requirements, planning must include both logical and topological components.

Architecting SharePoint Components

Just as you’d expect an architect designing your home to be familiar with the tools required to plan for and build your house, you will need to learn the components contained within SharePoint that you can use to build your organization’s SharePoint design architecture. You can arrange the various elements that make up your architecture in a variety of ways, depending on your isolation and sharing requirements. Isolation and sharing tend to be competing priorities, and to create a successful design that meets your needs, you need not only to understand what your goals are for each but also to examine your willingness to benefit from one element at the expense of the other. The following offers a high-level view of the logical SharePoint architectural components.

The Server Farm

At its most basic level, a server farm is a collection of physical server iron and logical servers grouped in a single location. The server farm is the top-level element in your design structure, and each server farm offers physical isolation of your resources from other server farms. SharePoint can be deployed in a single farm or across multiple server farms depending on your requirements. What determines whether you deploy on a single farm or in multiple farms depends on the following circumstances:

• Needing multiple dedicated services farms to accommodate heavier use of specific services
• Having separate operational divisions of responsibility in your organization requiring isolation of resources
• Funding that is dedicated for specific purposes requiring more than one farm
• Using separate datacenter locations
• Satisfying any industry or legal requirements for physical isolation between sites for your organization
• Using multiple server farms to enhance performance and scalability as well as licensing requirements and publishing environment goals

In general, if you plan on freely sharing multiple resources in your SharePoint environment, a single server farm is likely sufficient. If you require services and resources to be isolated for any of the reasons previously listed, you will likely require several server farms and probably one server farm per isolation requirement.

Of course, it is possible to satisfy at least some isolation requirements in a single server farm through the use of different Internet Information Services (IIS) application pools using different process identities, providing isolation for sites and service applications at the process level. However, in an enterprise-level environment with its needs operating and changing dynamically on many levels, planning for multiple server farms is the better option, assuming isolation is weighted more heavily than budget concerns.

Service Applications

In MOSS 2007, services were contained in shared services providers (SSPs). For SharePoint Server 2010, individual services are hosted in Microsoft SharePoint Foundation 2010, or what used to be called Windows SharePoint Services (WSS). This allows configuration of individual services, making management more flexible and letting third-parties create and provide customized services.

Service applications are associated with web applications, and specific services are typically deployed as needed in a particular farm. Only deployed services are referred to as service applications. This is a huge advantage in terms of conserving resources and optimizing performance. For instance, a specific web application can be configured to use only the services it needs rather than all the services available in a package.

The number of service applications that exist is vast, and, as previously mentioned, third-party vendors can create their own services for SharePoint Server 2010. A partial list of services includes the following:

• Access Services
• Business Connectivity Services (BCS)
• Excel Services
• Managed Metadata Services (MMS)
• Microsoft Office PerformancePoint Server 2007
• Visio Services

You can set up a single service application to be shared among multiple web applications or deploy multiple instances of the same service across a farm and, in some cases, across multiple farms. Also, there is no limitation regarding the number of services that can be deployed in any single farm.

A typical planning scenario requires that you either set up services to share across multiple web applications or isolate an individual service to one or a limited number of web applications.

Application Pools

As defined in Internet Information Services (IIS) 7.0, an Application Pool is a collection of one or more URLs that are serviced by one or a set of worker processes. You must select an existing Application Pool or create a new pool whenever you create a service or site collection in SharePoint Server 2010.

IIS application pools allow multiple SharePoint websites to run on a single server without the processes or code in one site interacting with any other sites. This is primarily a security benefit, since any outside intrusion on one site is isolated. Also, problematic or poor code running on one site is isolated so that other sites on the server are unaffected. For these reasons, you should plan to use dedicated application pools to isolate authenticated content and separate applications that contain password information.

Web Applications

A web application is any individual IIS website created to access and use SharePoint Server 2010 technologies and services, and each web application has its own domain name. Web applications in SharePoint Server 2010 use zones to contain and apply different access and policy rules for different sets of users. This is a particular advantage in managing large numbers of SharePoint users who need to access the same site but view and interact with different levels of content.

Planning for web applications should center on the need to either share or isolate specific web content. For instance, different content can be presented for authenticated vs. anonymous users, or information can be contained so that internal employees, customers, and partners all access different types of web content.

Policies for a web application let you set security and permissions at the level of the web application. You can set policies in Active Directory Domain Services users and user groups but not in SharePoint groups. Best practice suggests using these features to manage large numbers of users in user groups.

Zones

Zones are different logical paths expressed as URLs that allow access to the same web application. A web application can support up to five zones. The available zone names are Default, Extranet, Intranet, Internet, and Custom, and only one particular zone name can be used per web application. Zones using the same name across different web applications typically are available for the same user pool to control access for that group. For instance, your internal employees can use the Intranet zone to access all of the SharePoint sites configured to use that zone, giving that group the same sort of access to all relevant web applications. In effect, each zone is expressed as a separate website in IIS. Zones isolate users based on authentication type, network zone, and policy.

When planning for zone deployment, particular attention must be paid to the Default zone, since access to this zone may be gained by anyone who is able to use a link to this zone, such as a URL sent via an automated administrative email. The Default zone or any zone used for an outward-facing site must possess a high level of security.

Content Databases

A content database is not the database server itself but the container for all the content for a single web application. That is, you have one content database for one web application; however, you can separate content for multiple websites into multiple content databases for a site collection. You can also use a single content database for multiple site collections, keeping in mind that the site collection or collections represent a single web app.

Isolation and sharing are expressed as the difference between one site collection using one database and numerous site collections sharing a database. The number of site collections using a database is also a scaling and performance issue. If you are deploying site collections with a high workload attached and greater expectancy for growth, make sure to use fewer site collections per database.

You can also plan your content database strategy by adding databases to site collections as they grow or associate specific site collections only with specific content databases. The latter approach lets you isolate a database serving particular site collections from all the other databases and thus isolate the content it contains.

Site Collections

A site collection is a grouping of SharePoint sites that all share the same administrative settings and all have the same owner. Each site collection has a top-level site and can contain multiple subsites.

Planning for sharing and isolation in a site collection deployment includes considerations for access to site content and navigation. For instance, you can set permissions on the top-level site to be either inherited or not inherited by subsites; however, permissions cannot be inherited between site collections nor can navigation be shared across collections.

Other planning issues before creating one or more site collections are developing a consistent URL scheme for the collections and determining how to use collections to contain or separate different organizational elements in your company.

A site collection comprises a hierarchical structure of subunits that can include different types subsites used for different purposes.

Sites These are the individual site components within any given site collection and can be composed of lists, libraries, documents, or other web pages. All sites within a site collection share a common navigational structure. Also, all sites within a site collection are vulnerable to scripting exploits from other sites within the domain. Both navigation and exploit vulnerabilities as described are isolated within the site collection.

My Sites These are specialized sites within SharePoint and are enabled by default as part of the User Profile service. They share the same properties and characteristics as any other site in a site collection.

Authentication

This is a particularly sensitive element in SharePoint Server 2010 in terms of planning. Once a user has authenticated into SharePoint, authorization determines which sites, site content, and other information the user can access. There are three methods of authentication available in SharePoint Server 2010:

• Standard Windows IIS authentication
• Claims-based authentication built on a collection of .NET Framework classes called Windows Identity Foundation, which allows a direct connection to your company’s identity management system
• Forms-based authentication, which allows connections to more than one identity management system and does not use Active Directory

The chief planning consideration for authentication is the level of security required for a given web environment. There are three basic environments to consider:

• Internal Intranet
• External for Collaboration
• External for Anonymous Access

The recommended authentication method for Internal Intranet sites is Active Directory Domain Services (AD DS) if Active Directory is available. Authentication should be set up in a separate zone for external collaboration sites to allow access to the site by individual contributors only via a partner organization. By definition, anonymous access sites do not have authentication requirements, but you can use forms-based authentication if you want to have users register for tracking purposes.

An authentication scheme must be planned not only for SharePoint users but also for content crawling across web applications by the index component of the search server. Authentication methods for web applications are created when the application is created and the search crawler moves across a web application by zones, with the Default zone being first by default.

Planning considerations for crawler authentication of web application zones include the method of authentication for zones and the polling order set for the zones. If authentication for the crawler fails at a particular zone, the crawler stops and does not attempt to access other zones later in the polling order. You generally want to use the most stringent authentication for the Default zone, which the crawler will first encounter. Windows Challenge/Response (NTLM) is the method of choice for the Default site, relative to planning authentication for crawling.

Continuity and Crisis Planning

The last major planning concern is to design your system for when something goes wrong. In other words, how are you going to continue doing business, at least as far as SharePoint is concerned, if an emergency or disaster occurs at the local, regional, or national level?

Although you may immediately consider events such as an earthquake, hurricane, or flood, the first continuity issue you should really think about is at the level of the user. Users can overwrite or accidentally delete key content that can have a detrimental effect on your company. Fortunately, SharePoint Server 2010 has a number of systems in place to respond to such events.

The Records Center site is specifically designed to act as a repository for all your company’s critical legal and regulatory documents, preserving them so that, even if a user’s local copy should be “misplaced,” the content remains contained and available.

The Recycle Bin operates using a two-part process. Users with sufficient permissions can recover elements such as items, lists, and libraries using stage one, while site collection administrators can employ stage-two recovery to retrieve anything already deleted from the stage-one recycle bin.

Versioning is available to allow you to revert to an earlier version of a document should unwanted changes be saved or should the current version of the document become corrupt. Recovery of prior document versions can be performed by the document owners without administrator assistance, once versioning is enabled in SharePoint.

If the aforementioned methods do not suffice to recover lost elements or if a larger-scale crisis occurs, the backup and recovery system is available. The primary planning consideration is determining what components to protect using SharePoint backup, including the level of granularity for each component. This should help you determine also what type of backup tool to use, what backup method to employ, and how complete of a recovery process you want to implement.

The bottom line for backup and recovery is time and money. Setting up and implementing a system to back up and recover everything is a nice goal, but how long will the backup process take? Is every little bit of information contained in SharePoint truly something you couldn’t live without or recover through some other process? How much is a particular piece of information worth to your business vs. the cost of implementing a plan to protect it?

Architecting SharePoint Topologies

Whether you are deploying SharePoint Server 2010 on a single server or throughout a server farm using a large array of hardware, SharePoint uses a traditional three-tier server role model for the provision of SharePoint in an environment. These three basic roles can be configured in a variety of topological designs, from small testing environments, small server farms, and medium architectures up to large farm deployments containing server roles in dedicated groups. To plan for your specific needs, you’ll first need to understand the required server roles.

Server Roles

SharePoint’s default required server roles are web server, application server, and database server. Depending on your requirements and the configuration of the server topology, all three roles can be contained on a single server computer, with two devices, or can be deployed across a series of servers, with one or more dedicated to a single role.

Web Servers

Web servers host websites, web pages, web services, and web parts, providing content to users via HTML documents, Cascading Style Sheets (CSS) documents, code such as JavaScript, images, and other content. SharePoint is a web-based interface, and web services are required to allow access to applications and SharePoint services. The role does not have to be explicitly present in large, dedicated search farms, since web servers can connect to query servers directly from remote farms. However, in a small farm environment, the web server role is required and can be housed on a server computer also providing the query role.

The web server role by definition does not contain elements required for service applications, and no services besides web services run on the server computer.

Application Servers

Application software is installed on the computer hardware used to fulfill this role so that the services can be delivered to the SharePoint environment. Depending on the size of the environment and business requirements, the server computer can share this role with other roles, and more than one application can be installed on a single computer. Often in larger farms, a server computer will have several applications installed, which are usually grouped by similar usage and performance.

The application server role contains related roles and components based on the size of the farm on which they’re deployed. Two basic deployments exist: services on a single farm deployment cannot be shared with other farms, and services on cross-farm deployments can be shared across multiple farms.

Single farm: client-related services provide the following:

• Excel Calculation Services
• Access Services
• Word Services
• Word Viewing
• PowerPoint
• Visio Graphics Services

Single farm: other, more generic deployments contain the following:

• Usage and Health Data Collection
• Performance Point
• State Service
• Master Data Service
• Microsoft SharePoint Foundation Subscription Settings

Cross-farm: search roles provide the following:

• Query services which include query components and index partitions
• Crawl services, which includes search administration elements and crawlers

Cross-farm: other, more generic services contain the following:

• Business Data Connectivity
• Managed Metadata
• Secure Store Services
• User Profile
• Web Analytics

In addition to the various components that run on the server for service applications, numerous necessary services run directly on the server, including but not limited to the following:

• Access Database Services
• Business Data Connectivity
• Excel Calculation Services
• Lotus Notes Connector
• Performance Point Service
• Search Query and Site Settings Service
• Secure Store Service
• SharePoint Server Search
• User Profile Service
• Word Automation Services

Database Servers

This role provides all database services for the SharePoint environment. In a small farm deployment, this role can be assigned to a computer server containing one or more of the other roles. In large, enterprise-server farm environments, server hardware is dedicated to the database role and grouped together.

• This role also contains related roles and components based on what specific task or tasks the database will be performing: Content database servers contain multiple content databases depending on the amount of information required for the SharePoint environment.
• Search databases contain multiple property and crawl databases as well as the search admin database.

Service databases: other services contain the following components:

• Business Data Connectivity
• Managed Metadata
• Service Store Service
• State Service
• Usage and Health Data Collection
• Windows SharePoint Services Subscription Settings
• User Profile databases:
  • Profile
  • Profile synchronization
  • Social tagging

Server Farm Topology Overview

Depending on your requirements, server farms have a number of different scaling profiles, and depending on the selected profiles, server roles are deployed in different manners. This can require as little as one server computer for a single-server farm limited deployment up to multiple server computers, each dedicated to providing a specific role and grouped by services, components, or usage similarities.

Limited-Server Farm Deployment

The single-server farm deployment is typically used for testing or training, and all server roles are installed on a single server machine. This deployment can support up to 100 users.

The two-server farm deployment installs the web and application server roles on one computer server, while database services are housed on a separate machine. This deployment can accommodate up to 10,000 users.

Small Farm Deployment

Small server farms are expressed in different designs based on the number of expected users, how the SharePoint environment will be required to scale over time, and the importance of search for your users.

Two-Tier Topology A two-tier topology can service up to 10,000 to 20,000 users.

Three-Tier Topology A three-tier topology requires a dedicated application server when moderate service usage is expected.

Three-Tier Topology Optimized for Search A three-tier topology optimized for search requires a dedicated search database server computer and a second database computer to fulfill all other database requirements. With this configuration, search is optimized for up to 10 million individual items.

Medium Farm Deployment

This is represented by only a single farm topological design that is optimized for search for up to 40 million individual items. Each of the services provided by the different server roles should be scaled based on utilization requirements, amount of content, and growth needs. If search volume is expected to exceed the recommended limits for this design, deploy a separate search farm to satisfy your requirements.

How many web servers you add to this deployment depends on the number of users served. A good rule of thumb, at least initially, is to deploy one web server for every 10,000 users you expect to access SharePoint. Then monitor usage over time, and adjust your web server design accordingly.

For the application server role, begin by deploying the role on a single server computer, except for search services, which should inhabit a separate, dedicated computer. Monitor the usage of specific services to determine how to scale out the application server deployment. Often Excel Services receives heavy usage, and you may need to expand your early application server deployment by adding additional hardware for this service.

Hardware for database services should be divided between search databases and all other database services within the farm, scaling for access and utilization.

Large Farm Deployments

If you require a large farm design, it means your service utilization requirements, including search, are at the level of the enterprise organization. In this case, all services and databases should be grouped according to the similarity of characteristics and performance on dedicated server hardware. For instance, you can create a group of web servers to manage just incoming requests and a second group for administration and crawling.

Multiple Server Farm Topology Overview

So far, all the topology designs reviewed apply to individual server farms of various sizes; however, to accommodate enterprise-level business requirements, you will need to employ a multifarm deployment.

Only some services can be shared across farms, while others are limited for use within a single farm. All client-facing services are able to be shared only within a single farm environment.

Services that are contained within a single farm are as follows:

• Master Data Services
• Project
• State Service
• Performance Point
• Usage and Health Data Collection

These are the client-facing services:

• Access Service
• Excel Services
• PowerPoint
• Word Automation Services
• Word Viewing
• Visio Graphics Service

Services that can be shared across multiple farms are as follows:

• Business Data Connectivity
• Managed Metadata
• Search
• Secure Store Service
• User Profile
• Web Analytics

Multiple Server Farm Design

Deploying multiple server farms does not mean deploying multiple identical server farms. Each farm is constructed to fulfill a specific role within the organization. There is usually a farm that acts as the primary enterprise services farm and then separate farms that are specialized by department, service, or content. Also, not all farms contain all server roles. Some farms may contain only application servers and depend on other farms for database and web services. Other farms may contain two role types.

The types of multiple server farm designs and deployments are numerous and can be highly variable, given the large collection of possible requirements. The following examples are the most common topologies and will provide you with an idea of how a multiple server farm infrastructure is constructed and how the farms interact.

Company Collaboration Farm This is usually the most varied of server farm environments, containing a mix of services that can be shared across farms and those contained within individual farms. The farm can, but doesn’t have to, possess the database server role and can delegate database services to a different farm. This farm generally contains web and application servers and must include all client-facing services. Application servers are pooled into different groups depending on function. For instance, you can have one application pool that contains just client-facing services and another for services used for websites such as team sites.

Enterprise Services Farm This farm usually contains only application pools providing services that can be shared across all server farms used by your organization.

Published Content Farm This farm contains no services but rather offers all published web content. Any services required by this farm are provided by one or more separate farms.

Specialized Department Farm If you have one or more departments or teams within your company requiring access and utilization restrictions that are significantly high, you can deploy a specialized farm to offer the services specifically needed by this department. This also has security benefits, isolating the department’s content from other farms and thus other parts of the organization, letting the department have direct control over managing its own metadata.

Other Multifarm Designs As previously mentioned, a multiple farm environment doesn’t have to be organized in the fashion just presented. For instance, if search is a priority for your enterprise, you can create a server farm dedicated just to search and another farm to provide all other SharePoint services. You can also create a primary corporate collaboration farm, as previously mentioned, and then create separate farms to service each of the departments within the company. You can even deploy multiple farms in a nonenterprise SharePoint environment by designing farms exclusively for each of your company’s departments without any other farm specialization.

SharePoint Server 2010: Deploying and Upgrading

In general, if you plan to utilize SharePoint Server 2010 in your business infrastructure, either you will be deploying it as a new installation or you will be upgrading from a previous version of SharePoint. Upgrade planning and procedures will be specific to a currently existing Microsoft Office SharePoint Server 2007 deployment. Planning and deploying a clean install of SharePoint Server 2010 will be presented first. The upgrade planning activities, including additional topological information, will be subsequently presented in the “Upgrading to SharePoint Server 2010” section later in this chapter.

Deploying SharePoint Server 2010

For you to administer SharePoint Server 2010, you must be able to demonstrate the ability to deploy SharePoint across a number of installation and configuration scenarios. For the purpose of following the exercises presented in this chapter and in the rest of the book, the primary focus will be on deploying SharePoint on a single-server machine with a built-in database. This will be the deployment version you will likely use to study for the exam and was the scenario used in writing this book.

However, you must also be proficient in deploying SharePoint Server 2010 in environments where database services are provided by a Microsoft SQL Server instance and in multiple-machine architectures.

SharePoint Server 2010 Licensing

There are two licensed versions of SharePoint Server 2010 available for download and deployment:

SharePoint Server 2010 (Enterprise Client Access License Features) This licensing option is used primarily for organizations needing to create either customer-facing Internet site or internal extranet sites and needing to have access to the complete set of enterprise features and capacities of SharePoint.

SharePoint Server 2010 for Internet Sites, Enterprise This licensing option is used primarily for organizations needing to create public-facing Internet sites or basic internal extranet sites and needing access only to SharePoint’s standard collaboration features.

Deploying SharePoint on a Single Server with a Built-in Database

This installation and initial configuration process is a multistep process but is the fastest way to deploy SharePoint Server 2010, since you are working with a single-server deployment that does not require a separate database server setup. This deployment is primarily used to evaluate SharePoint and test its new and updated features and capacities. This configuration was also the setup used to write this book and is ideal for the student preparing for the 70-667 certification exam.

Required tasks performed by this installation include the following:

• Microsoft SQL Server 2008 Express is installed.
• The SharePoint Products And Technologies Configuration Wizard creates the configuration database and content database for SharePoint sites.
• The SharePoint Products and Technologies Configuration Wizard installs the SharePoint Central Administration website.

The following exercises map to the requirements for installing and performing the initial configuration tasks for SharePoint Server 2010 on a single server with a built-in database.

You must have downloaded the file for the SharePoint 2010 Internet Sites executable onto the device, virtual or actual, where you plan to install SharePoint. You must also have access to the product key and be an administrator on the local server.

In Exercise 2-1, you will install the prerequisite software on a server prior to installing SharePoint.

You will be returned to the SharePoint Server 2010 splash screen and are ready to immediately install SharePoint Server 2010. You must have the product key for your version of SharePoint Server 2010 available at this time.

Exercise 2-2 shows you how to perform a SharePoint Server 2010 single-server installation from the point of running the Setup.exe file.

Once you have successfully installed SharePoint Server 2010 and completed the SharePoint Products Configuration Wizard (Psconfig.exe), there are some post-installation tasks to perform such as creating the first site collection.

In Exercise 2-3, you will create the first site collection after SharePoint Server 2010 is installed.

It may take a few minutes for the site collection to be created. Once finished, a confirmation page will appear stating that the new top-level site was successfully created. You can either click the link to open the new top-level site in a new browser window or click OK to return to the Central Administration page.

When you open the new top-level site, you will be asked to authenticate again. Afterward, the site opens, as shown in Figure 2-1.

In the previous example, you used the default web application. There are actually two web applications installed by default: SharePoint – 80 and SharePoint Central Administration v4. The SharePoint – 80 web application is the only one available in which to begin to create site collections, and it uses port 80 by default. For a number of reasons, including security, you may want to create additional web applications for your site collections.

A web application is an Internet Information Services (IIS) website that is a logical container for your site collections. Creating one or more web applications is a prerequisite to creating site collections, and each application is represented by a separate IIS website defined by a shared or unique application pool. When you create a web application, you should give it a unique domain name for easy identification and to inhibit cross-site scripting attacks.

To create a web application, besides requiring access to SharePoint Central Administration, you must be a member of the Farm Administrators SharePoint group, and if you are using SQL Server for database services, you will also need to be a member of the SQL Server fixed server roles dbcreator and sysadmin.

You can use a number of methods to create a new web application. In Exercise 2-4, I’ll show you the most basic method of creating a new web application.

Deploy a Single Server with SQL Server

Contrary to what you may think, a server farm can be as small as one or two physical machines, at least in the beginning. A farm can consist of a single SharePoint server and a single SQL database server. The significant difference in the setup is not just selecting Server Farm instead of Standalone, but also running the Farm Configuration Wizard after you’ve completed the installation and after running the SharePoint Products And Technologies Configuration Wizard.

A critical prerequisite is that you must be able to provide credentials for several different account types to deploy a server farm. Those accounts are as follows:

SQL Server Service Account Used to run SQL server.

Setup User Account Used to run both Setup and the SharePoint Products And Technologies Configuration Wizard.

Server Farm Account or Database Access Account Used to configure and manage the farm, to act as the application pool identity in Central Administration, and to run the SharePoint Foundation Workflow Timer service.

Installing Software Prerequisites

Install the software prerequisites on the designated server hardware running Windows Server 2008 or Windows Server 2008 R2 just as you did in Exercise 2-1. The task is identical.

Installing SharePoint Server 2010 as a Single Server in a Server Farm

The installation process begins exactly as it did in Exercise 2-2, steps 1 through 3. When the Choose The Installation You Want page appears, perform the following steps:

If you are prompted for a username and password again, you will need to add the Central Administration website to the list of trusted sites in your Internet Explorer browser and configure the authentication settings. You may also want to disable Enhanced Security in Internet Explorer. If you are using a proxy server, you may receive an error message indicating that you need to configure the proxy server settings to bypass the proxy server.

On the SharePoint server farm page, you can run the wizard to configure the farm or perform the task manually. See the next section, “Multiple Servers for a Three-Tier Farm,” for more.

Multiple Servers for a Three-Tier Farm

A two-tier server farm is composed of one or more servers offering web and application services on the first tier and one or more servers offering database services on the database tier. A three-tier farm creates individual levels for web and application servers.

Before proceeding, you will need to make sure that all your Windows Server 2008, Windows Server 2008 R2, SQL Server 2005, and SQL Server 2008 machines are fully patched and updated. You also need to run the Microsoft SharePoint 2010 Products Preparation tool on each of the Windows Server 2008 and 2008 R2 machines to verify that they are fully compatible with SharePoint.

In general, it’s recommended that you run the preparation tool on all machines first, then install the software prerequisites on all machines, then install SharePoint Server 2010 on the machines, then run the SharePoint Products And Technologies Configuration Wizard, and then create the server farm. SharePoint is usually installed on web servers before application servers.

Installing SharePoint Server 2010 on Server Farm Servers

After you install the software prerequisites on all servers, you can perform the SharePoint server farm installation on each server, as described in the earlier “Installing SharePoint Server 2010 as a Single Server in a Server Farm” section. After the installation, do not immediately run the SharePoint Products And Technologies Configuration Wizard.

Creating and Configuring the Server Farm

These are the typical steps to installing SharePoint in a server farm environment. This list presents the information at a high level:

Installing Language Packs

Internationalization is often a key factor in any large organization’s business strategy. Whether you are offering your products to a multinational audience or are working with global partners, it’s important to be able to present your web content in more than one language. Regardless of whether you’re installing SharePoint Server 2010 as your first SharePoint deployment or upgrading from a prior version of SharePoint, if you need to interact with site users who speak and read more than just a single language, the ability to install language packs for SharePoint Server 2010 is important.

Language packs are additional site templates that contain languages besides the default English and can be installed on web servers that will be accessed from worldwide locations. When a site or site collection is created with one of these templates, all the content within the site is presented in the language for which the template was created. You can only create new sites and site collections with such templates. A template in another language cannot be applied to an already created “English-only” site with the expectation that the content will be rewritten in another language.

SharePoint Server 2010 comes in different language versions including English, French, and Spanish. If, for instance, you install the French version of SharePoint and later need to deploy additional sites in English, you will need to install the English language pack on the web server that will be accessed by your English-speaking audience. To create a site or site collection in a language other than the default, you must install that language pack before creating those sites.

Acquiring Language Packs

Individual language packs support only a single language per language pack, so you only need to download the files for the languages you want to support. If you plan to use more than one language pack, avoid overwriting a prior download with a subsequent language pack by selecting different directories for each download. You can download language packs from here:

www.microsoft.com/downloads/details.aspx?FamilyId=a0c7c05d-8fca-4391-bc70-b62c9af91123&displaylang=en

Preparing a Web Server for Language Pack Installation

A web server requires that you have installed the additional language files needed, have installed SharePoint Server 2010, and run the SharePoint Products And Technologies Configuration Wizard before you install the language packs. Installing additional language files on Windows Server 2008 is a straightforward task. You must be an administrator on the local machine.

Once the required files have been installed, you can proceed to the next part of the process, installing the language pack.

Installing a Language Pack

Installing a language pack is relatively simple. Go to the download page, select the necessary language pack, and then download it to the desired directory on a SharePoint web server. Launch the executable and follow the steps in the installation wizard.

The critical part of the process is to run the SharePoint Products And Technologies Configuration Wizard after you’ve installed the language pack. Failure to do so will mean that the language pack will not be installed properly. To run the SharePoint Products And Technologies Configuration Wizard again, do the following:

Final Deployment Tasks

During the initial deployment of SharePoint, you may have encountered some issues or errors in your Internet Explorer web browser associated with security. The following can be used in response if these circumstances arise.

Adding Central Administration Web Site to Trusted Sites

After running the SharePoint Products And Technologies Configuration Wizard, if you are prompted to authenticate again to access Central Administration, you will likely need to add that site to Internet Explorer’s list of trusted sites.

Disabling Internet Explorer Enhanced Security Settings

If you still have difficulty getting Internet Explorer to correctly load the Central Administration site or any other site you deem both safe and necessary in SharePoint, you can perform the following steps to disable IE’s enhanced security:

Configuring Proxy Server Settings to Bypass the Proxy Server for Local Addresses

If you are using a proxy server and you see a proxy server error message when you attempt to access the Central Administration site or another site you deem safe and necessary in SharePoint, perform the following steps to set the proxy server settings to bypass local addresses:

Post-installation Configuration

A number of post-installation configuration settings are required, including configuring incoming and outgoing email alerts, configuring search, and setting up optional mobile account notification.

See Chapter 4 for information on configuring incoming email, outgoing email, and mobile account alerts as post-installation tasks. See Chapter 5, “Configuring Indexing and Search,” for information on configuring search settings as a post-installation task.

Upgrading to SharePoint Server 2010

Upgrading from Microsoft Office SharePoint Server 2007 to SharePoint Server 2010 involves many unique challenges, not the least of which is upgrading all your hardware to 64-bit platforms. Also, all of your Windows Server and SQL Server machines have to conform to the requirements necessary to run SharePoint Server 2010.

What Is Visual Upgrade?

They say you should never judge a book by its cover, but the “look and feel” is very important in UI design. When Microsoft introduced the Ribbon to the Windows Vista and Microsoft Office 2007 interfaces, there was a great outcry among users because the location and function of all the controls and features they were used to using dramatically changed. Sometimes people don’t like change.

The Visual Upgrade feature allows the server administrator or owner of a particular site collection to determine the appearance of a site collection or collections post-upgrade. Although the default look and feel is MOSS 2007, the administrator performing the upgrade can change the appearance of all site collections to SharePoint Server 2010, and the change will be accomplished during the upgrade. The administrator can also let site owners make that decision. For instance, using an in-place upgrade, after a site is upgraded, a site owner can use the preview option to view the site collection appearance. At that point, the site owner can either accept the visual upgrade or revert to the MOSS 2007 if desired.

Planning and Preparing for Upgrade

There are a wide variety of factors to consider well before initiating the upgrade. Unlike creating a SharePoint Server 2010 environment from scratch, you need to take what you have already built under MOSS 2007 and preserve as much of the infrastructure and content as possible, taking down as little of your production environment for as brief amount of time as possible.

To be sure you are as prepared as possible, consider the following practices for upgrading.

Review Supported Upgrade Paths

You may well expect that with the right preparation, you can upgrade your MOSS 2007 environment to SharePoint Server 2010, which is basically true, but there are a number of deployment considerations that can get in the way. For instance, you must deploy to the same type of topology you are starting with. Also, some SharePoint editions do not have a direct upgrade path to SharePoint Server 2010.

Upgrade Topologies Paths

The specific topology you are starting with will determine your upgrade options:

MOSS 2007 Stand-Alone Server with SQL Server 2005 Express Edition This topology can be upgraded only to a SharePoint Server 2010 stand-alone server with Microsoft SQL Server 2008 Express. It cannot be upgraded to any farm topology.

MOSS 2007 Single Server with SQL Server This topology can be upgraded to a SharePoint Server 2010 single server with SQL Server but not to a stand-alone server with SQL Server 2008 Express.

Any Size MOSS 2007 Farm Topology This can be upgraded to any size SharePoint Server 2010 farm topology but not to any stand-alone deployment.

Upgrade Products Paths

Standard editions can be upgraded only to Standard editions, and Enterprise editions can be upgraded only to Enterprise editions, which means you cannot upgrade MOSS 2007 Standard edition to SharePoint Server 2010 Enterprise edition. That said, you can upgrade SharePoint Server 2010 Standard to SharePoint Server 2010 Enterprise.

A number of cross-product upgrades are supported:

• You can upgrade SharePoint Foundation 2010, Microsoft Office Forms Server 2007, and Microsoft Office PerformancePoint Server 2007 to SharePoint Server 2010.
• Microsoft Search Server 2007 can be upgraded to either SharePoint Server 2010 or Microsoft Search Server 2010.
• Microsoft Office Project Server 2007 with Windows SharePoint Services 3.0 with SP2 or Office SharePoint Server 2007 with SP2 can be upgraded to SharePoint Server 2010 Enterprise edition plus Microsoft Project 2010.

SharePoint Server 2010 Upgrading Practices

In addition to reviewing the hardware, server, database, and application requirements as already recommended, you must take care to address the following issues:

• Make sure MOSS 2007 on all servers has Service Pack 2 or newer applied.
• Correct any issues with any applications that may not be working or not working well, and uninstall any software that is no longer being used. Any problems you leave behind could cause the upgrade to fail.
• Upgrade all your server hardware to 64-bit, upgrade server software to Windows Server 2008 Service Pack 1 (SP1) and Cumulative Update 2 or Windows Server 2008 R2, and upgrade database software to SQL Server 2005 SP3 and Cumulative Update 3 or SQL Server 2008.
• Do not add any server hardware after beginning the upgrade process.
• Run the pre-upgrade checker to verify and correct any outstanding issues.
• Perform a full backup of your current SharePoint environment prior to the upgrade.

SharePoint Server 2010 Approaches

Depending on various factors, you will need to choose a specific method or approach to performing the upgrade once you have met all the prerequisites. Once you’ve selected an approach, you should perform a trial upgrade on a single server to determine any special issues you may face. This will allow you to correct the problem before the full-scale upgrade, or if it cannot be easily corrected, you can develop a plan for anticipating the problem and use a workaround.

Four common upgrade methods are available:

In-Place Upgrade This upgrade method allows you to install SharePoint Server 2010 on the same hardware that you have MOSS 2007 installed, also upgrading all of your content and configuration settings in the server farm. This has the benefit of letting you perform the upgrade in one stroke as well as preserving all or almost all of your data and setup. The dark side of this method is that in order to perform the upgrade in a single action, you need to take your server farm offline completely during the upgrade process, meaning that SharePoint will not be available at all. This is the quickest of the upgrade paths.

Database Attach Upgrade This method allows you to upgrade the content of your server farm when you move from MOSS 2007 to SharePoint Server 2010 without upgrading the configuration settings. This approach is most often used when you want to upgrade your hardware or modify your server farm topology at the same time. The process requires that you first configure a new server or server farm using SharePoint Server 2010.

The chief advantage is that you can upgrade numerous content databases at the same time, making the overall upgrade faster. You can even combine multiple farms into a single farm while upgrading. The chief disadvantage is that no server or farm settings are upgraded in the process. You are required to manually transfer the settings from the MOSS 2007 environment to the SharePoint Server 2010 environment.

Hybrid Approach 1: Read-Only Databases The chief feature of this upgrade approach is setting your databases to read-only, which allows content to be read during the upgrade. This means your existing server farm remains up and running, minimizing the downtime from the SharePoint user point of view. This method lets you upgrade multiple databases simultaneously as well as upgrade hardware.

As with the database attach upgrade method, the server and farm settings are not upgraded and must be manually configured. This goes for any specialized settings you may have made in MOSS 2007.

Hybrid Approach 2: Detach Databases This approach somewhat combines the advantages of the first two methods, letting you perform an in-place upgrade for the content and settings while detaching and upgrading your databases in a parallel process. This preserves not only your data and farm settings but also any customizations you may have made. You can also upgrade numerous content databases simultaneously, speeding up the upgrade process.

There are few disadvantages to the approach, except that, like all the methods already mentioned except for the in-place upgrade method, you will need to plan for the amount of time it takes to transmit databases over your network and be able to directly access all of your database servers.

Perform the Pre-upgrade Checks

The SharePoint Server 2010 pre-upgrade checker is an Stsadm.exe command-line operation that you run on your MOSS 2007 platform to discover any potential issues that might prevent or inhibit the upgrade to SharePoint Server 2010. You must have Service Pack 2 installed for this option to be available.

The pre-upgrade checker, once run, produces a report on the following:

• A list of all servers and farm elements and an upgrade readiness report for all servers
• A list of alternate access mapping URLs used in the farm
• A list of all installed site definitions, site templates, features, and language packs installed in the server farm
• A list of all customizations not supported by the upgrade
• A list of any database or site orphaned objects in the farm, such as lists, list items, and websites
• A list of any missing or invalid configuration settings
• An upgrade readiness report on all databases

If, after viewing the reports, you determine that you need to postpone the upgrade until any deficits have been corrected, you can remedy the outstanding issues and then run the pre-upgrade checker again to verify that everything has been corrected.

To run the pre-upgrade checker, you must be a member of the local Administrators group on the server running MOSS 2007. Perform the following actions to proceed:

The pre-upgrade checker runs on the local server and examines your server farm settings. Once finished, the report will open in your web browser. You can also view the report here:

Performing an In-Place Upgrade to SharePoint Server 2010

Before initiating the upgrade, back up your entire MOSS 2007 server farm including all of your SQL server databases. Practice restoring the server farm and databases, making sure the backup and restore process is successful before you begin the upgrade.

There are four general steps in performing this method of upgrade from MOSS 2007 to SharePoint Server 2010:

Running the Prerequisite Installer

Prior to running the SharePoint Server 2010 setup, you must run the prerequisite installer on each MOSS 2007 web server in order to be able to install the software needed to support SharePoint Server 2010.

Running SharePoint Server 2010 Setup

After you have completed installing the prerequisite software, you must run Setup.exe on all of your MOSS 2007 web servers. The setup process is virtually identical to how a fresh install is conducted.

After you have run the installation on all your web servers, you can proceed with running the SharePoint Products And Technologies Configuration Wizard on each of your web servers starting with the server containing the Central Administration page.

Running the SharePoint Products and Technologies Configuration Wizard for Upgrade

To start the configuration wizard, click Start ⇒ Administrative Tools ⇒ SharePoint Products And Technologies Configuration Wizard. Then proceed through the wizard in the same manner as when you run it during a fresh install, until the Visual Upgrade page appears.

Performing Post-upgrade Application Service Tasks for an In-Place Upgrade

Once you have completed the in-place upgrade process, there are some additional tasks to perform, since SharePoint Server 2010 has a number of new services that didn’t exist under MOSS 2007. The most straightforward way to enable the service applications to host any new services in the current server farm is to use the Farm Configuration Wizard in Central Administration under Upgrade And Migration.

Upgrading the Taxonomy Data for Profile Services for an In-Place Upgrade

Taxonomy data is used to classify data so it can be standardized, shared, and used on multiple systems. Under MOSS 2007, taxonomy data is stored in the shared services provider (SSP) database as part of the Profile Services data. In SharePoint Server 2010, this data must be moved to the managed metadata database. You are required to create a service application for the Managed Metadata service before you can move and upgrade the data.

After that is accomplished, use Windows PowerShell to reconnect the data to the Managed Metadata and User Profile service applications. You must be 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 is installed.

Performing a Database Attach Upgrade to SharePoint Server 2010

As you previously read, the database attach upgrade method allows you to upgrade only the content in your SharePoint environment from MOSS 2007 to SharePoint Server 2010 without upgrading your configuration settings. This approach lets you change server hardware or your server farm topology as part of the upgrade.

Before beginning the upgrade from MOSS 2007 to SharePoint Server 2010, you must create a new server farm environment. The first part of creating the new environment involves installing SharePoint 2010 using the steps you reviewed in the earlier “Multiple Servers for a Three-Tier Farm” section. If necessary, revisit that part of this chapter before proceeding.

Next, you must create a new web application for each one that existed in the old SharePoint environment.

Then manually re-create each server farm configuration setting including the following:

• Outgoing email server
• All server farm–level security and permission settings
• All services settings including search settings
• Included paths
• Quota templates

Manually transfer all of your customization settings to the new farm environment including the following:

• Custom site definitions
• Custom style sheets
• Custom web parts
• Custom web services
• Custom features and solutions
• All administrator-approved form templates and data connection files
• Language packs

To export form templates and data connection files using the command line, type Stsadm.exe -o exportipfsadminobjects -filename <path to export CAB>; then press Enter.

To import the files into the new environment using Windows PowerShell, type Import-SPIPAdministrationFiles; then press Enter.

When you perform a database attach upgrade, you are essentially backing up your databases from the old MOSS 2007 server farm and restoring them in the new SharePoint Server 2010 server farm. This is what allows you to change your server hardware at the same time as you upgrade SharePoint. During the restore, the upgrade process runs, upgrading the entire database.

As previously mentioned, you must first verify that all your software and hardware meet the required specifications for your desired SharePoint Server 2010 environment, including SQL Server. You must also belong to the db_owner fixed database role and the db_backupoperator fixed database role on the database servers and belong to the dbcreator fixed server role and the db_owner fixed database role in the server farm to which the database will be attached. Additionally, you must be a member of the local Administrators group on all the servers you will be using for the upgrade.

There are two basic steps to performing the upgrade:

• Backing up the MOSS 2007 databases using SQL Server tools
• Restoring the database backup to the new farm

Backing Up the Database

This procedure must be performed physically at the machine or machines hosting the SQL Server database for MOSS 2007.

Restoring the Database on SQL Server 2005 and 2008 Enterprise Editions

Although the backup process is identical for both SQL Server 2005 and SQL Server 2008, the restore process is slightly different. The following instructions can be used on both editions of the SQL database server:

Verifying the Presence of Custom Components for the Database

Once the database has been restored, you must connect the database to web applications. Before you can approach this task, you must first verify that you have all the custom components that are required. You can do this with Windows PowerShell.

On the SQL Server instance, open Windows PowerShell. At the command prompt, run the cmdlet:

The root site for the web application must be included in the first content database that you add when you add the content databases. This means that you must review the root of the web application from the original server farm to make sure of the location of the first site collection. Then, after adding the database to the root site, you can add the other content databases for the web application. The process of adding databases automatically creates any required site collections.

Adding a Content Database to a Web Application

Once you have verified that you possess all the required customizations, you can proceed to add a content database to a web application using the Stsadm.exe command-line and the addcontentdb operation.

On the command line, run the type the following command and parameters; then press Enter:

Post-upgrade Tasks for a Database Attach Upgrade

The next step is to upgrade the taxonomy data for profile services. This task is identical to the one you reviewed earlier in this chapter in the section “Upgrading the Taxonomy Data for Profile Services for an In-Place Upgrade.”

Updating InfoPath Form Template Links

During the database attach upgrade process, all InfoPath form templates were exported from the old environment and imported into the new environment. Now that the upgrade is complete, you still need to update the links to point to the correct URLs for the form templates. You do this using Windows PowerShell. To complete this task, you must be 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.

After completing this process, move to the “Final Upgrade Tasks” section of this chapter.

Final Upgrade Tasks

Even under the best of circumstances, you’ll still want to review the records on the upgrade to determine whether there were any problems. Of course, if errors occurred, you’ll want to view the logs and diagnose the issues so that you can correct them.

Verifying the Upgrade Status

As you’ve already experienced, the upgrade process, regardless of procedure, consists of several distinct processes, any of which could experience difficulties. You may not want to wait until the upgrade is complete to discover any issues that may have occurred. There are a number of different tasks you can engage in to verify whether your upgrade is progressing well and has completed successfully.

Reviewing the log and error files can be performed during portions of the overall upgrade process and after the upgrade is complete. For instance, once Setup.exe has run, the SharePoint Products And Technologies Configuration Wizard has completed, and the Central Administration website opens, then the content upgrade commences, and you can review the setup and configuration log files and error files. To view the log files, you will need to be a local Administrator on the server.

To review the Setup.exe log files, use Windows Explorer, navigate to %USERTEMP% or %WINDIR%Usersuser accountAppDataLocalTemp, and then locate the SharePoint Server SetupYYYYMMDDHHMMSSSSS.log file, where YYYYMMDD is the date and HHMMSSSSS is the time. Hours are formatted on a 24-hour clock and include minutes, seconds, and milliseconds.

To review the SharePoint Products And Technologies Configuration Wizard log file, navigate to this location using Windows Explorer:

Look for PSCDiagnostics_MM_DD_YYYY_HH_MM_SS_SSS_randomnumber.log where MM_DD_YY is the date and HH_MM_SS_SSS is the time. Hours are also formatted on a 24-hour clock using the same pattern as the Setup.exe log files.

To review the upgrade log file and error log file once the upgrade has completed, navigate to here:

To locate the upgrade log, look for Upgrade-YYYYMMDD-HHMMSS-SSS.log. To locate the error log file, look for Upgrade-YYYYMMDD-HHMMSS-SSS.err.

These files will open in any text editor such as Notepad. If all has gone well, you should see a message in the upgrade log file that states “Upgrade session finished successfully!” If this message is missing, use the Find function to search for ERROR to locate entries related to component and database connection failures. Search for WARNING to find issues related to missing components or features. You may also have to use a log parser to run queries against the log files. Once you find and resolve any issues, you can restart the upgrade.

In addition to reviewing the log files, you can also verify the upgrade by using the Central Administration website to view the version number on the Servers In Farm page. You must be a member of the Farm Administrators group to perform this task. In Central Administration, under the System Settings section, click Manage Servers In This Farm. Under Farm Information, next to Configuration Database Version, make sure the number starts with 14.

You can also check the upgrade status from the Central Administration home page under Upgrade And Migration by clicking Check Upgrade Status. You can view the upgrade status from the command line by opening a command line window and navigating directories to this location:

Then enter Stsadm -o localupgradestatus and press Enter. The localupgradestatus operation does not take any parameters. This operation is effective only on the local server and cannot check on other servers in the farm. You will be notified if any server components still need to be upgraded.

Reviewing Upgraded Sites

Once the upgrade has completed, you will want to view your upgraded sites to verify that they appear as expected. If you used Visual Upgrade, you can use this feature to preview the sites directly. You can also check the Site Settings page by using the URL http:// siteurl/_layouts/settings.aspx, where siteurl is the URL specific to the desired site. If using the Site Settings page isn’t effective, go back to your log files to see whether the problem is listed.

To be complete, test all of your web parts by building a web parts page that uses all of your customized web parts. Determine whether any of them seem broken. Also test to see whether the styles and appearance of your web pages are as expected. Often if there is a problem, the most likely solution is to correct a broken link to one or more items. Be especially diligent in checking any special customizations, and verify that all permissions work for all of your groups.

Restarting the Upgrade

If you encountered problems with the initial upgrade anywhere along the line and then corrected them, you’ll need to restart the upgrade to finish the job. For instance, if during an in-place upgrade should the server restart or the upgrade should otherwise fail, you’ll need to restart the upgrade at the part of the process where the SharePoint Products And Technologies Configuration Wizard (Psconfig.exe) runs.

For a database attach upgrade, any sites that cannot be upgraded will be skipped in the upgrade process; after the outstanding issues have been fixed, you can restart the upgrade for just the skipped sites by using Windows PowerShell.

Restarting the Server Farm Upgrade from the Command Line

You must be a member of the local Administrators group on the server to perform thefollowing steps:

where passphrase is the string you originally configured for server farm security; then press Enter.

Any sites that were skipped during the in-place or database attach upgrade will now be upgraded.

Restarting the Upgrade for a Database Using Windows PowerShell

To perform this task, you must be a member of the SharePoint_Shell_Access role on the configuration database and a member of WSS_ADMIN_WPG local group on the server machine hosting SharePoint 2010.

The upgrade for the database will commence.

This completes the majority of tasks associated with a fresh install of SharePoint Server 2010 and the two major upgrade paths from MOSS 2007 to SharePoint Server 2010. There are still a number of configuration duties to be performed to get your SharePoint environment up and running effectively.

Summary

In this chapter, you received an extensive summary of how to install SharePoint Server 2010 as well as how to upgrade from MOSS 2007 to SharePoint Server 2010.

• Planning a hardware, software, and topology environment for a fresh installation of SharePoint Server 2010
• Planning various approaches for upgrading MOSS 2007 to SharePoint Server 2010
• Performing a fresh installation of SharePoint Server 2010 on a single server with built-in database
• Exploring other SharePoint Server 2010 installation scenarios
• Reviewing the different approaches to upgrading MOSS 2007 to SharePoint Server 2010
• Examining and performing post-installation and post-upgrade tasks

Exam Essentials

Planning the SharePoint Server 2010 Environment Understand how to architect the components in SharePoint including the server farm, service applications, applications pools, and so on. Also demonstrate the ability to architect SharePoint topologies in relation to server roles and server farm design.

Deploying and Upgrading SharePoint Server 2010 Display your knowledge in deploying SharePoint Server 2010 in the areas of licensing, installation prerequisites, and installation and deployment types and methods through post-installation tasks.

Review Questions

1. What are some of the factors that determine whether you deploy SharePoint Server 2010 on a single farm or on multiple farms? (Choose all that apply.)

A. The requirement to use the Visual Upgrade feature

B. The need for multiple dedicated server farms to satisfy use requirements

C. Funding that is dedicated for special purposes requiring more than one farm

D. Using multiple server farms to enhance performance

2. Which of the following are valid service applications in SharePoint Server 2010? (Choose all that apply.)

A. Access Services

B. Business Community Services (BCS)

C. Excel Services

D. Visio Services

3. What is true about application pools in SharePoint Server 2010? (Choose all that apply.)

A. Application pools are defined by Internet Information Services (IIS) 6.0.

B. An application pool is a collection of one or more URLs serviced by one or a set of worker processes.

C. IIS application pools allow multiple SharePoint websites to run on a single server without processes in one site interacting with any of the other sites.

D. Dedicated application pools increase security for authenticated content.

4. What is true for web applications in SharePoint Server 2010? (Choose all that apply.)

A. A web application is any individual IIS website created to access and use SharePoint Server 2010.

B. A web application is any individual IIS site collection created to access and useSharePoint Server 2010.

C. Each web application has its own individual domain name.

D. Each web application shares a domain name path.

5. Zones are different logical paths expressed as URLs that allow access to the same web application. Which of the available zones requires the greatest security?

A. Default

B. Extranet

C. Intranet

D. Internet

E. Custom

6. In your continuity and crisis planning, in protecting data from errors made by SharePoint users, which of the following are considered to be the most appropriate safeguards? (Choose all that apply.)

A. The Records Center is a specifically designed repository that protects all legal and regulatory documents.

B. The Recycle Bin uses a two-part process that allows recovery of deleted data.

C. Versioning allows a document to be reverted to an earlier version should the current version become damaged or corrupted.

D. All documents must be fully backed up every night to be protected from user errorsor damage.

7. In architecting SharePoint topologies, if you are deploying a single farm, which services can you expect to be available just on your individual farm? (Choose all that apply.)

A. Business Data Connectivity

B. Excel Calculation Services

C. Query Services

D. Word Services

8. The database server role provides all database services for SharePoint. This role must contain several required components. Which components would you expect to find? (Choose all that apply.)

A. Business Data Connectivity

B. Service Store Service

C. State Service

D. Word Automation Services

9. A limited server farm deployment is typically used to test a new SharePoint deployment or for training purposes. This deployment can support about 100 users and employs a single hardware server. You can also deploy SharePoint on a small farm deployment, the next step up from limited server farm deployment, and use two physical servers, one for web and application server roles and the other for the database. How many users can you expect to support in a small farm deployment?

A. 500

B. 1,000

C. 10,000

D. 20,000

10. In planning for a multiple-server farm design, what is true about such designs? (Choose all that apply.)

A. Not all farms in a multifarm design must have the same topology.

B. All farms in a multifarm design must use the same topology.

C. A farm in a multifarm design can rely on web servers on other farms and does not have to contain web servers of its own.

D. The enterprise services farm topology is the default topology for a multiserverfarm design.

11. Deploying SharePoint Server 2010 on a single server with a built-in database is often used for testing SharePoint or for training. For this installation type, which of the following are required tasks? (Choose all that apply.)

A. Microsoft SQL Server 2005 Express must be installed.

B. Microsoft SQL Server 2008 Express must be installed.

C. The SharePoint Products And Technologies Wizard must create the SharePoint Central Administration website.

D. The SharePoint Products And Technologies Wizard must create all the site collections for SharePoint.

12. For the SharePoint Server 2010 on a single server with a built-in database installation, you typically run the SharePoint Products And Technologies Wizard immediately after you finish running Setup.exe. If the configuration wizard should fail, what are your options? (Choose all that apply.)

A. On the Configuration Failed page, click the available link to locate the PSCDiagnostics log files in order to determine the problem.

B. Navigate to %COMMONPROGRAMFILES%Microsoft SharedWeb Server Extensions14LOGS to locate the log files and attempt to determine the problem.

C. On the Configuration Failed page, under Repair Or Remove, select Repair.

D. On the SharePoint Server 2010 splash screen, under Install, click Install SharePoint Server. When prompted to choose Repair or Remove, select Repair.

13. One of the post-installation tasks for a single-server installation with a built-in database is to create at least one web application. If you choose not to create a web application, what are your options for deploying a site collection?

A. You will be unable to create a site collection until you create the first web application.

B. The only web application created by default once SharePoint is installed is SharePoint Central Administration v4, and you can only create additional site collections using this web app.

C. The SharePoint – 80 and SharePoint Central Administration v4 web applications are created by default, but you can only use SharePoint – 80 to create site collections.

D. The SharePoint – 80 and SharePoint Central Administration v4 web applications are created by default, and you can use both web apps to create site collections.

14. You are a SharePoint Server 2010 administrator, and you have installed language packs for French, German, and Spanish so that you can create site collections using those languages for your company’s European customers. You have just deployed a partner site collection in French and have received feedback that some of the site content is still in English. Of the following, what could be the cause?

A. After installing the language pack, you forgot to rerun the SharePoint Products And Technologies Wizard, resulting in some corruption in the site collection’s content when it was created.

B. One of the other SharePoint administrators in your organization manually translated some of the content into English by mistake.

C. Some content in language packs for site collections is created in English by default, so this is no error.

D. Some content, such as error messages and dialog boxes, depend on technologies outside the language pack and may appear in English.

15. You are a SharePoint 2010 administrator, and you have just finished installing SharePoint Server 2010 as a single-server deployment. You have opened the Central Administration website but have experienced some errors. What are the likely errors and their solutions? (Choose all that apply.)

A. Internet Explorer 8 security may be interfering with Central Administration being opened correctly; you can add the Central Administration site to the Trusted Sites list in IE8.

B. The default Internet Explorer enhanced security settings on your server may be interfering with Central Administration being opened correctly; you can disable those settings for the Administrator account in Administrative Tools using the Server Manager page.

C. The Internet Explorer 8 default accessibility settings may not be correctly set; you can go into Internet Options to permit greater accessibility by using the Advanced tab.

D. If you are using a proxy server, Internet Explorer 8 may be blocking access to the proxy server; you can set IE8 to bypass the proxy server for local addresses.

16. You are the SharePoint administrator for your company, and you are in the process of upgrading your MOSS 2007 environment to SharePoint Server 2010. You are using SharePoint Visual Upgrade and giving the site administrators for the SharePoint site collections access to this tool. Of the following, what do you expect the site administrators to do with Visual Upgrade?

A. The site administrators can use the Visual Upgrade UI to perform upgrades to their site collections using a graphical tool to drag and drop sites into new topologies.

B. The site administrators can preview what their site collections will look like using Visual Upgrade and decide whether they want the sites to use the old MOSS 2007 look or the new SharePoint Server 2010 look.

C. The site administrators can use Visual Upgrade to preview site collection organization, navigational links, and application pool connections.

D. Site administrators do not have sufficient access permissions to use Visual Upgrade, which can be operated only by the SharePoint administrator group.

17. You are the SharePoint administrator for your company, and you’ve been tasked with developing a plan to upgrade your current MOSS 2007 deployment to SharePoint Server 2010. You currently administer your MOSS 2007 server farm with separate tiers for web servers, application servers, and database servers. Your environment uses the Office SharePoint Server 2007 Enterprise edition. Of the following, which are valid upgrade paths to SharePoint Server 2010? (Choose all that apply.)

A. You can upgrade to a SharePoint Server 2010 single-server deployment using SQL Server 2005.

B. You can upgrade to a SharePoint Server 2010 server farm deployment using the same topology of separate tiers for each of the three server roles.

C. You can upgrade to a SharePoint Server 2010 server farm deployment with a two-tier topology, with web and application server roles on one tier and database servers on a separate tier.

D. You can upgrade to any SharePoint Server 2010 Standard edition single or server farm deployment.

18. You are the SharePoint administrator for your organization. You have been tasked with upgrading your MOSS 2007 server farm to SharePoint Server 2010. You require an upgrade procedure that upgrades both your content databases and configuration settings at the same time. You have been assured by your CIO that you can take SharePoint offline for an extensive period of time, and you are required to perform little or no manual configuration of the system during the upgrade. Which is the most viable upgrade path for you to take given these parameters?

A. In-place upgrade

B. Database attach upgrade

C. Hybrid approach 1: read-only databases

D. Hybrid approach 2: detach databases

19. You are the SharePoint administrator for your organization, and you are going to perform an in-place upgrade of your MOSS 2007 environment to SharePoint Server 2010. You have run Setup.exe on all your web servers and are about to run the SharePoint Products And Technologies Configuration Wizard. Are there any conditions regarding which server the wizard must be run on first?

A. You must run the wizard first on the web server hosting the Central Administration website.

B. You must run the wizard first on the web server that experiences the greatest use by SharePoint users.

C. You must run the wizard first on the web server that experiences the least use by SharePoint users.

D. There is no preference.

20. You are the SharePoint administrator for your organization, and you have just upgraded your MOSS 2007 platform to SharePoint Server 2010. Now you must manage SharePoint’s taxonomy data. Taxonomy data is used to classify data so it can be standardized, shared, and used on multiple systems. The upgrade process from MOSS 2007 to SharePoint Server 2010 requires that you move this data from the shared services provider (SSP) database to the managed metadata database. How can you accomplish this task?

A. On the command line, use Stsadm.exe and the required parameters to initiate the move.

B. Use the appropriate commands and parameters in Windows PowerShell to initiatethe move.

C. Use the Central Administration server farm management tools to initiate the move.

D. Rerun the SharePoint Products And Technologies Configuration wizard to initiatethe move.

Answers to Review Questions

1. B, C, D. Option A is bogus, because the use of Visual Upgrade has nothing to do with server farm planning. All other options are correct.

2. A, C, D. Business Community Services (BCS) is incorrect. The correct name is Business Connectivity Services (BCS). All other options are valid services.

3. B, C, D. For option A, application pools are defined by IIS 7.0, not 6.0. All other options are correct.

4. A, C. Options B and D are bogus. All other options are correct.

5. A. The Default zone, or any customer-facing zone, requires the greatest attention since access to this zone may be gained by anyone who can use a link to the zone.

6. A, B, C. Although you want to create and use a sufficient backup and recovery strategy, conducting a full backup of all documentation on a daily basis is not good resource management, especially to protect each individual document contained in SharePoint. Backup is the last possible resort for protecting a document from loss.

7. B, D. Only Excel Calculation Services and Word Services are confined to a single server farm. Business Data Connectivity and Query Services are available across multiple farms.

8. A, B, C. You would typically find Word Automation Services on an application server role but not commonly on a database server role.

9. C. A two-tier small farm deployment involving two physical server machines can support up to 10,000 users.

10. A, C. Not all farms in a multiserver farm design must be the same, and in fact an individual farm doesn’t have to contain any web servers and can rely on web servers contained in a separate farm. There is no particular default topology for a multifarm design.

11. B, C. The built-in database for this installation is always Microsoft SQL Server 2008 Express. Microsoft SQL Server 2005 Express is bogus. Although the SharePoint Products And Technologies Wizard creates the configuration and content databases for SharePoint as well as the Central Administration website, it does not actually create the site collections.

12. A, B, D. You can either click the link on the Configuration Failed page or manually navigate to the location of the log files to determine what went wrong. You can also return to the SharePoint Server 2010 splash screen to initiate a repair, but you cannot initiate a repair directly from the Configuration Failed page.

13. C. Although both the SharePoint – 80 and SharePoint Central Administration v4 web applications are created by default, the Central Administration v4 web application is for the exclusive use of the Central Administration website. To create site collections for all other purposes, you must use the SharePoint – 80 web application, unless you choose to create additional web applications.

14. D. Assuming the default language for your SharePoint Server 2010 deployment is English, you can use one or more language packs to create site collections from templates that render the content in another language. However, some features, such as notifications, dialog boxes, and error messages, depend on other technologies like Microsoft .NET Framework, Microsoft Windows Workflow Foundation, and Microsoft ASP.NET and therefore may not be localized for the desired language. Not running the configuration wizard after installing the language pack would not have resulted in a working site collection at all, so option A is incorrect. Options B and C are bogus.

15. A, B, D. Option C is bogus. All other options are valid.

16. B. Visual Upgrade is a tool that lets you preview and determine how site collections will appear after the upgrade. All the other options are bogus.

17. B, C. You can upgrade any size MOSS 2007 server farm to any size SharePoint Server 2010 server farm but cannot upgrade from a server farm topology to any form of single-server deployment. Also, an Enterprise edition of SharePoint cannot upgrade to a Standard version, and vice versa.

18. D. Although the in-place upgrade may seem a logical choice, it is the quickest upgrade path, and part of the parameters for the upgrade is that time is not an issue. The detach databases combines the advantages of all the other methods, but it does take longer than the in-place upgrade.

19. A. The SharePoint Products And Technologies Configuration Wizard must first be run on the web server hosting Central Administration, since the Central Administration site is the interface providing administration tools for managing the rest of the farm. Afterward, you can run the wizard on your other web servers in any order. The other options are bogus.

20. B. To initiate the move, you need to open Windows PowerShell and execute the command Move-SPProfileManagedMetadataProperty -ProfileServiceApplicationProxy <SPServiceApplicationProxyPipeBind> -Identity <string>. All other options are bogus.