We’re happy to announce the availability of MCTS Self-Paced Training Kit (Exam 70-667): Configuring Microsoft SharePoint 2010 (9780735638853) by Dan Holme and Alistair Matthews. You can buy your copy here or here.
This book is an exam prep guide for MCTS exam 70-667 for IT Professionals who need to configure Microsoft SharePoint 2010. The book will take you through a series of lessons and reviews that fully cover each exam objective. It includes case scenarios and practice exercises so you can practice what you learn. The CD contains practice tests to reinforce your understanding of the technology and help you prepare for the certification exam.
Creating a SharePoint 2010 Intranet
Microsoft SharePoint Server 2010 offers a broad range of functionality that addresses a vast number of business collaboration scenarios. In this Training Kit, you will learn to configure and support SharePoint Server 2010, but of course you must begin at the beginning, and in this chapter you will learn what it takes to get SharePoint up and running—from preparing your infrastructure, to configuring related technologies and products, to deploying SharePoint servers and farms using both out-of-the-box installation wizards and scripts, and finally to creating a simple web application to serve as a corporate intranet.
Exam objectives in this chapter:
- Deploy new installations and upgrades.
- Configure SharePoint farms
- Manage accounts and user roles.
- Manage web applications.
- Manage site collections.
Lessons in this chapter:
- Lesson 1: Prepare for SharePoint 2010
- Lesson 2: Install and Configure SharePoint 2010
- Lesson 3: Create a SharePoint Intranet
Before You Begin
To complete the lessons in this chapter, you must build your lab environment according to the instructions found in the Introduction to this Training Kit.
Nothing could be easier than installing SharePoint Server 2010, right? Not so fast. SharePoint 2010 relies on a deep, rich stack of technologies, including 64-bit versions of Windows Server, SQL Server, Internet Information Services (IIS), the .NET Framework, and Windows PowerShell. There’s also a lengthy list of software and configuration prerequisites. So although it’s possible to log on as a domain administrator, pop the SharePoint Server 2010 DVD into a server, and have a stand-alone installation of SharePoint up and running in less than an hour, that doesn’t mean it’s a production-ready farm that meets all of the technical, security, and business requirements of your SharePoint governance plan. Even something as seemingly straightforward as SharePoint installation requires careful preparation, consideration for least privilege and other security best practices, and preferably a small investment in scripting and automation to ensure a smooth and consistent installation in both test and production environments.
Lesson 1: Prepare for SharePoint 2010
Microsoft SharePoint Server 2010 is a platform that relies on a wide range of other Microsoft technologies. Before you can install SharePoint 2010, you must prepare your hardware and software environment to support the dependencies and interactions with SharePoint products and technologies.
After this lesson, you will be able to:
■ Identify the roles and topologies of SharePoint farms.
■ Describe the infrastructure requirements for installing SharePoint 2010.
■ Describe the client browser and application requirements for installing SharePoint 2010.
■ Describe the interaction between SharePoint services, Active Directory, and Microsoft SQL Server.
■ Create the user accounts required to install SharePoint.
■ Assign permissions and rights required to install SharePoint.
■ Describe the software and configuration prerequisites for installing SharePoint 2010.
■ Install the software prerequisites for SharePoint.
Estimated lesson time: 60 minutes
Prepare the Server Infrastructure
Before you can install SharePoint Server 2010, you must prepare one or more servers to host the SharePoint farm. The following sections outline the considerations and requirements for your SharePoint server infrastructure.
SharePoint Components and Topologies
A SharePoint implementation consists of numerous components, including web applications, services, and databases. Web applications are websites with which users interact, such as your corporate intranet. Services include the crawler that indexes content for search. All SharePoint content and most SharePoint configurations are stored in databases hosted by one or more instances of SQL Server.
These components can be hosted by one or more servers in a SharePoint farm. The consolidation or distribution of components determines the farm’s topology. A single-server farm runs both SQL Server and SharePoint—and all SharePoint components—on one server. A single-server farm is often appropriate for training and development environments, and may be used for sites with low utilization patterns, such as a small, remote office.
SQL Server performance is critical to the overall performance of a SharePoint farm. For that reason, most organizations choose to run SQL Server on a server or cluster that is separate from the servers running the SharePoint farm. A farm with a dedicated server running all SharePoint components, separate from the SQL Server server or cluster, can support higher levels of utilization.
However, a SharePoint farm with only one server running SharePoint offers no redundancy for SharePoint itself. If the server fails, SharePoint sites are not available. For
this reason, it is a best practice to have at least two servers running SharePoint in a farm, and to run components on both servers that are important to the operations of your organization, based on the service-level agreements (SLAs) specified by your SharePoint governance plan. For example, most organizations would want search services to be available in the event of the failure of a single server. To achieve this service objective, you must ensure that a search query component is installed on both servers in the SharePoint farm. Similarly, if it is important that the intranet web application is available even if a server fails, you must ensure that the web application is accessible on both servers in the farm.
By distributing and load balancing web applications, and by installing services on multiple servers, you also gain performance efficiencies. Load balancing distributes requests for content from web applications across servers. SharePoint automatically distributes requests to services across the servers that run those services.
BEST PRACTICES SCALING OUT THE FARM
You might imagine that the best practice to scale out a farm is simply to add more servers and to continue adding all services to each server. In fact, in larger and more complex environments performance is optimized by dedicating servers to specific tasks. For example, indexing content from numerous content sources is a performance- intensive task. It is therefore common for organizations to configure a SharePoint server with only the search index component, allowing the server to focus its resources on this task.
As you scale out your farm, you should first ensure that services and web applications are redundant to a level that meets the SLAs of your governance plan. You must also ensure that performance is optimized. By balancing availability and performance, you can determine the correct topology for your SharePoint implementation
In previous versions of SharePoint, much documentation referred to web front-end (WFE) servers, which hosted only user-facing web applications, and application
servers, which hosted services such as indexing. In SharePoint 2010, although you can still create a topology in which user-facing web applications and SharePoint services run on separate servers, the range of available topologies is much greater. It will therefore be more common to mix services and web applications on the same server, with the goal of optimizing availability and performance. However, old habits are hard to break, and the SharePoint community, SharePoint resources and documentation, and even this Training Kit are likely to continue referring to WFE and application servers.
Hardware and Software Requirements
SharePoint Server 2010 is a powerful platform that can scale to meet the most demanding enterprise scenarios. As such, the hardware requirements for SharePoint begin with a minimum hardware base with at least four processor cores running 2.5 GHz and 8 GB of RAM.
SharePoint 2010 is a 64-bit platform, and therefore you must use 64-bit versions of the operating system on each SharePoint server and for SQL Server. Windows Server 2008 with Service Pack 2 (SP2) (64-bit) or Windows Server 2008 R2 (which is only 64-bit) is required.
SQL Server is the required database platform. SharePoint 2010 requires one of the following:
■ SQL Server 2005 with Service Pack 3 (SP3) with Cumulative Update 3 (64-bit)
■ SQL Server 2008 SP1 with Cumulative Update 2 or Cumulative Update 5 or later (64-bit)
■ SQL Server 2008 R2 (which is only 64-bit)
MORE INFO MINIMUM HARDWARE AND SOFTWARE REQUIREMENTS
You can find the minimum hardware and software requirements for SharePoint Server 2010 in a Microsoft TechNet article at http://technet.microsoft.com/en-us/library/cc262485.aspx.
It is highly recommended that you use the latest versions of the operating system and SQL Server to take advantage of the maximum number of features. For example, you need SQL Server 2008 R2 to take advantage of failover, PowerPivot, and Access Services reporting features.
While it is recommended that you use the latest versions of the operating system and SQL Server in a production environment, the exam may test your awareness of minimum supported versions as well.
If you are investing in infrastructure for Microsoft Office SharePoint Server 2007, invest in 64-bit servers, operating systems, and software now to reduce the number of steps required to migrate to SharePoint Server 2010. Migration from 32-bit to 64-bit platforms is detailed in Chapter 9, “Deploying and Upgrading to SharePoint 2010.”
Microsoft allows you to install SharePoint on a client operating system to support development. The following are supported, with at least 4 GB of RAM:
■ Windows Vista with Service Pack 1 (SP1) or later (64-bit)
■ Windows 7 (64-bit)
Such platforms should not be used for production purposes.
MORE INFO PREPARING A DEVELOPMENT ENVIRONMENT
You can learn more about installing SharePoint on a Windows client in a Microsoft TechNet article at http://go.microsoft.com/fwlink/?LinkID=164557.
You can also access SharePoint through a hosted service such as one of the following offerings from Microsoft and its partners:
■ Microsoft Online (http://www.microsoft.com/online) offers Office 365, a per-user subscription to SharePoint as well as to Microsoft Exchange and Microsoft Office LiveMeeting. Microsoft Online also offers dedicated SharePoint hosting to large customers.
■ Microsoft will offer customers the ability to serve their public-facing web sites on hosted instances of SharePoint Server 2010. Details are not available at the time of publication.
■ Microsoft’s consumer and small business services, such as Windows Live, provide some SharePoint functionality. For example, Windows Live SkyDrive allows users to edit Word, Excel, PowerPoint, and OneNote documents in the browser, which is functionality provided by Office Web Apps.
You can mix and match internally hosted farms with externally hosted services to meet varied business requirements.
SharePoint licensing is complex because of the number of products that are involved. It is important that you consult with your licensing representative to ensure compliance for your SharePoint implementation.
The most typical implementation involves purchasing licenses for Windows Server 2008 or Windows Server 2008 R2 for each SharePoint server and a quantity of per-user client access licenses (CALs) for each SharePoint user. SQL Server is typically installed with a per-processor license, which does not require CALs for users.
If you are using SharePoint Foundation 2010, no additional license is required. If you are using SharePoint Server 2010, however, you need a server product license for each SharePoint server and CALs for each user. SharePoint Standard CAL provides access to the basic level of SharePoint Server 2010 functionality including My Sites and search. With the Enterprise CAL, which is an add-on to the Standard CAL, you can deploy features such as Excel Services and Office Web Applications.
MORE INFO SHAREPOINT EDITIONS
You can learn more about and compare the features of SharePoint Foundation, Standard, and Enterprise at http://sharepoint.microsoft.com/en-us/buy/Pages/Editions-Comparison.aspx.
If you provide content to users or devices that cannot be counted—for example, if you expose SharePoint content to the Internet for public access—you must use the SharePoint server-only license model, in which you purchase licenses to SharePoint Server for Internet Sites, Standard or Enterprise. If these servers provide content to both public and internal users, the licensing becomes more complex.
MORE INFO SHAREPOINT LICENSING
You can learn more about SharePoint licensing at http://sharepoint.microsoft.com/en-us/buy/Pages/Licensing-Details.aspx.
To minimize the cost of an enterprise SharePoint implementation, you should consider implementing multiple SharePoint farms, each with a level of functionality that supports the business requirements of users in different scenarios. For example, you might build a SharePoint farm in your enterprise datacenter on which you host your enterprise search, user My Sites, and Excel Services for business insights. This farm would support Enterprise features of SharePoint, and would be licensed accordingly.
If you also have a remote office where users require support for collaboration around documents and lists, you might build a farm running SharePoint Foundation in that remote site, instead of hosting the users’ collaboration sites at the enterprise datacenter, across the wide area network (WAN) link. Users in the remote office would continue to use the enterprise SharePoint farm for search and My Site functionality, but their day-to-day collaboration would take place on the local SharePoint Foundation farm, which would provide optimal performance and availability without increasing the cost of SharePoint licensing.
Browser and Application Requirements
SharePoint 2010 generates most of its content using web-standard eXtensible Hypertext Markup Language (XHTML) that renders well across most browsers. Microsoft categorizes browsers into two categories—Level 1 and Level 2—to help customers align browser choice with the desired level of functionality.
Level 1 browsers support ActiveX and all SharePoint functionality on user and administrative pages, as shown in Table 1-1.
Level 2 browsers support basic read, write, and administrative activities, as shown in Table 1-2.
Other standards-based browsers work with SharePoint with the same limitations as Level 2 browsers. However, Microsoft has not done extensive testing on browsers other than those listed, and does not support use of other browsers. If you want to use a browser other than one listed in the preceding tables, you should perform testing to ensure that the browser delivers an acceptable user experience.
For published sites, page designers can apply Web Content Management features to control markup and styling so that published sites are compatible with additional browsers, including Microsoft Internet Explorer 6. However, it is the page designer’s responsibility to create pages that target the browsers that are designated for support. Page designers and content authors must use a standards-based browser, such as Internet Explorer 8 or Firefox 3.5 to author content.
SharePoint compatible applications can provide a rich, client-side interaction with SharePoint. Microsoft Office 2003 and later are compatible with SharePoint.
MORE INFO PLANNING BROWSER SUPPORT
The following article provides additional details regarding browser support for SharePoint 2010: “Plan Browser Support” at http://technet.microsoft.com/en-us/library/cc263526.aspx.
Prepare User Accounts for SharePoint Administration and Services
SharePoint has close relationships with, and dependencies on, SQL Server and Active Directory.
Active Directory provides identity and authentication services. In other words, it stores user accounts (user names and passwords) and validates account logons. These services support users logging on to SharePoint sites. They also support the accounts used by SharePoint and SQL services themselves.
SQL Server stores almost all of the configuration and content of a SharePoint farm. SQL Server services, like all Windows services, run using an identity and log on with credentials consisting of a user name and password.
SharePoint services also run with Active Directory credentials. The credentials are used by SharePoint to access data in SQL Server. These accounts must have SQL logins so that SQL can authorize the access. These SQL logins are created automatically by SharePoint during setup and the creation of web applications.
To support the administration and services of SQL and SharePoint, you must create identities in Active Directory, and you must ensure that appropriate permissions have been granted. It is important that you adhere to the security practice of least privilege, in which an account is given only the permissions required to perform its tasks. The following accounts enable a least-privilege implementation of SharePoint in a typical environment:
■ SQL Server administrator account: SQL_Admin
■ SQL Server service account: SQL_Service
■ SharePoint setup user and administrator account: SP_Admin
■ SharePoint farm account: SP_Farm
■ Web and service application pool account(s): SP_WebApps and SP_ServiceApps
■ Search indexer (crawler) account: SP_Crawl
■ User profile synchronization account: SP_UserSync
The following sections provide detail about each of these accounts. Because these accounts are privileged, they should be dedicated for the indicated purpose, and should not be used for any other purpose in the enterprise.
SQL Server Administrator Account: SQL_Admin
To install SQL Server, an identity must be a member of the local Administrators group on the server that will host SQL Server. It is recommended that you use a unique account to install SQL Server instead of using your own account. This allows for future growth and change in the enterprise—when you get promoted or leave the organization, your account is not tied to the ownership of SQL Server or its databases. For example, you can create an account named SQL_Admin and add it to the local Administrators group of the server. Log on as SQL_Admin and install SQL Server. The SQL_Admin account will thus become the first administrator of the SQL Server instance, and the owner of several components and databases of SQL Server.
During or after the installation, you can specify additional administrators of SQL Server. At that time, add your account as an additional SQL Server administrator. You thus gain administrative privileges to SQL Server without registering your account as the owner of the SQL Server instance.
SQL Server Service Account: SQL_Service
SQL Server services use identities, or accounts. Like most Windows services, you can configure SQL Server services to use special identities such as System, Network Service, or Local Service, but it is a highly recommended best practice to use a domain user account. If SQL Server is running on a different server than SharePoint, you are required to use a domain account. The SQL Server service account is used as the identity for the MSSQLSERVER and SQLSERVERAGENT services. For example, create an account named SQL_Service. During installation of SQL Server, configure two services, MSSQLSERVER and SQLSERVERAGENT, to log on as SQL_Service.
SharePoint Administrator and Setup User Account: SP_Admin
The setup user account—for example, SP_Admin—is used by a human being to install and configure SharePoint.
During setup and configuration, SharePoint creates SQL databases and logins, and modifies the server itself (for example, by creating local groups). SharePoint setup and configuration use the credentials of SP_Admin to perform such tasks, so SP_Admin must be a domain user account that has been assigned the securityadmin and dbcreator roles on the SQL server. The account must also be a member of the local Administrators group of any server that will run SharePoint.
SP_Admin is the only account for which a SQL login must be manually created, and to which SQL roles must be assigned. During installation of SharePoint, the credentials of SP_Admin are used by the setup routines to automatically create SQL logins for—and to assign roles to—other accounts, such as SP_Farm.
SharePoint Farm Service Account: SP_Farm
During installation and configuration, the setup user, SP_Admin, assigns an account to the SharePoint farm. This account—for example, SP_Farm—is used by the Central Administration site’s application pool and as the identity for the Timer service. It must be a domain user account.
The permissions required by SP_Farm are assigned automatically during farm setup by the SharePoint Products Configuration Wizard. Specifically, the account is given a SQL Server login that is assigned the dbcreator and securityadmin fixed server roles. The account is also associated with the dbo login or assigned the db_owner fixed database role for all SharePoint databases in the farm. When additional servers are added to a farm, SP_Farm is automatically given the permissions it requires on those servers.
Both the SP_Admin and SP_Farm accounts are highly privileged. SP_Admin is used by a human being to install SharePoint, configure the farm, and add servers to or remove servers from the farm. On a day-to-day basis, SP_Farm acts as the service account for the farm, supporting Central Administration, timer jobs, and other components.
Web and Service Application Pool Accounts: SP_WebApps and SP_ServiceApps
Each web application runs in an application pool. The application pool identity is a domain user account that is functionally equivalent to a service account, with permissions to access the content database for the web application on the SQL Server. Service applications and services, such as Search or the Office Web Applications, also use domain user identities for application pool and service accounts.
When you assign an account to a web application, service, or service application, SharePoint 2010 automatically grants the account the permissions it needs. For example, when you assign an account as the default crawl account, which is used to index SharePoint content for search, SharePoint automatically grants the account permission to read all content in all sites.
You can use one or more accounts for web applications, service applications, and services based on your requirements for manageability and security. By using unique accounts for each application and service, you can create a least-privileged environment in which each application or service account has only the permissions required for that component. Additionally, you can more easily audit and troubleshoot because logs will clearly identify the account—and therefore the service—in question.
By using a single account for all applications and services, you eliminate the need to manage multiple accounts. However, the account will have the cumulative permissions
required for all applications and services, which means that any one application or service process will run with more permissions than it needs. And it will become more difficult to audit and troubleshoot certain scenarios, because logs will identify a single account and you cannot directly associate that account with a specific service or application.
In many products, it is difficult to manage service accounts because of password synchronization. When a service account’s password is changed in Active Directory, you must manually update the logon information for the service on each system on which the service is installed.
SharePoint 2010 introduces managed accounts, a feature that reduces the management overhead for service accounts. A managed account is a domain user account that is registered with SharePoint and assigned to one or more web applications, service applications, or services. When you change the password of a managed account, SharePoint automatically updates the logon information of the associated components. Additionally, SharePoint can automatically manage password changes so that changes are made just prior to the expiration of the password based on domain password policy.
As a result, managing service accounts for SharePoint 2010 is significantly easier than in previous versions of SharePoint, or in other products. By reducing the management burden of service accounts, SharePoint 2010 makes it possible for you to use one account per service or application. You will learn more about managed accounts in Chapter 9.
In this Training Kit, a single account, SP_ServiceApps, will be used for most service applications, and another account, SP_WebApps, will be used as the application pool identity for user-facing web applications. In a production environment, you should define accounts based on your requirements for security and manageability, with the understanding that defining unique accounts for each service and web application is a best practice.
Search Indexer (Crawler) Account: SP_Crawl
The search crawler account is used to index content. It is automatically given permissions to read all SharePoint content. It should be a unique account that cannot access content at any higher level. You must manually give it permission to read any other content source that you configure it to index, such as shared folders on servers.
User Profile Synchronization Account: SP_UserSync
SharePoint user profile synchronization uses an account to synchronize profile attributes between Active Directory and SharePoint. This account will be detailed in Chapter 6, “Configuring User Profiles and Social Networking.”
Install SharePoint Prerequisites
You must apply a long list of software and configuration prerequisites before you install SharePoint. The following are required:
■ Microsoft SQL Server
■ The Web Server (IIS) server role
■ The Application Server server role
■ Hotfix for Microsoft Windows (KB976394 for Windows Server 2008, KB976462 for Windows Server 2008 R2)
■ Windows Identity Foundation (KB974405)
■ Microsoft Sync Framework Runtime v1.0 (x64)
■ Microsoft Chart Controls for Microsoft .NET Framework 3.5
■ Microsoft Filter Pack 2.0
■ Microsoft SQL Server 2008 Analysis Services ADOMD.NET
■ Microsoft Server Speech Platform Runtime (x64)
■ Windows PowerShell 2.0 (for Windows Server 2008)
■ Microsoft Server Speech Recognition Language (Optional component supports phonetic search)
■ Microsoft SQL Server 2008 R2 Reporting Services (SSRS) Add-in for SharePoint Technologies (Optional component supports reporting services integration and Access Web services reporting)
The following sections will equip you to install these prerequisites. Details and links to all prerequisites can be found in the article “Hardware and software requirements (SharePoint Server 2010)” at http://technet.microsoft.com/en-us/library/cc262485.aspx.
Install SQL Server
You must install one of the versions of SQL Server discussed earlier in this lesson before you can install other SharePoint prerequisites. The Lab Environment Build Guide on the companion media provides instructions for preparing the lab environment for the practices in this Training Kit. The instructions include procedures for installing SQL Server. To install SQL Server in a production environment, you must follow the guidance in the SQL Server documentation. See Microsoft SQL Server 2008 Administrator’s Pocket Consultant, Second Edition by William R. Stanek for more information.
Microsoft SharePoint 2010 Products Preparation Tool
Microsoft SharePoint 2010 Products Preparation Tool (Preparation Tool), also known as the prerequisite installer, can download and install all of the prerequisites for you automatically.
To run the Preparation Tool, log on as the setup user account—for example, SP_Admin. The setup user account is described earlier in this lesson. Then, launch the tool from the Install Software Prerequisites link on the SharePoint Server 2010 Start page (default.hta), shown in Figure 1-1, or launch the tool directly by starting PrerequisiteInstaller.exe from the root of the installation media.
The Preparation Tool scans for each prerequisite. If a prerequisite is not found, the tool downloads, installs, and configures the prerequisite.
In the event of an error—for example, if downloading a prerequisite fails—the tool stops and produces an error message that indicates which prerequisite failed. You can find the details of the failure in the error log, which is located in the %TEMP% folder, or by clicking the Review The Log File link in the wizard. The tool displays a link to the log. After you have remedied the problem, rerun the tool. Repeat the process until all prerequisites have been installed and configured successfully.
Two prerequisites are optional: Microsoft Server Speech Recognition Language and Microsoft SQL Server 2008 R2 Reporting Services (SSRS) Add-in for SharePoint Technologies. If the Preparation Tool cannot find or install these prerequisites, it generates an error, but you can continue to the next step in installing SharePoint Server 2010.
Offline and Scripted Installation of Prerequisites
Many organizations do not allow servers to have direct access to the Internet. The Preparation Tool can be directed to install prerequisites from a specific location, such as a shared folder,
rather than downloading prerequisites from the Microsoft Download Center.
First, you must use a system that does have Internet connectivity to download all prerequisites to a shared folder. You can find links to prerequisites by using one of the following two options:
■ Links to prerequisites are listed at http://technet.microsoft.com/en-us/library/cc262485.aspx.
■ Run the Preparation Tool and examine the log for error messages that are generated when the tool attempts to download each prerequisite. The URL to each prerequisite is listed.
PrerequisiteInstaller.exe supports parameters that specify the location of each prerequisite. The syntax of each parameter is /PrerequisiteName:PathToInstallationFile. The path can be
a local or Universal Naming Convention (UNC) path to which the setup user (SP_Admin) account used to run the Preparation Tool has Read permission.
For example, the parameter used to indicate the location of the Microsoft Filter Pack 2.0 installation file is the following:
You can type PrerequisiteInstaller.exe /? to display the full list of parameters.
You can use PrerequisiteInstaller.exe and its parameters to script the installation of SharePoint prerequisites by using one of two methods:
■ Start Command Prompt, and then type a command line with PrerequisiteInstaller.exe and all of the parameters on a single command line.
■ Start Notepad and enter all parameters on a single line. Save the file as PrerequisiteInstallerArguments.txt in the same folder as PrerequisiteInstaller.exe. Then, run PrerequisiteInstaller.exe. It automatically looks for the arguments file, called PrerequisiteInstallerArguments.txt, in the working directory.
You will create and use a PrerequisiteInstallerArguments.txt file in the Practice for this lesson.
The /unattended parameter causes the Preparation Tool to run in silent, unattended mode. No prompts or messages are displayed. Use this mode only when you are confident that
prerequisite installation will be successful.
You must install and configure several prerequisites manually. The first two are updates that should be evaluated in the context of your enterprise. Use the following Knowledge Base
articles to determine whether the update is appropriate in your environment.
■ The ADO.NET Data Service Update is used by services like REST Web services: “An update is available that provides additional features and improvements for ADO.NET Data Services in the .NET Framework 3.5 SP1 on a computer that is running Windows 7 or Windows Server 2008 R2” at http://support.microsoft.com/kb/976127.
■ Update KB979917 for ASP.NET is required if you use claims-based authentication. “Two issues occur when you deploy an ASP.NET 2.0-based application on a server that is running IIS 7.0 or IIS 7.5 in Integrated mode” at http://support.microsoft.com/kb/979917.
You must also consider whether you need to disable loopback checking. Windows Server 2008 (and Windows Server 2008 R2) blocks access to a website if the request for the website
originates from the IP address of the server itself.
Loopback checking prevents you from using a browser on a SharePoint server to browse to a site on the same server farm. In a production environment, it is not recommended that you
log on to a SharePoint server and use a browser on the server. However, this usage scenario may be more common in a development, testing, or training environment.
Loopback checking also prevents SharePoint services—most notably the search crawler that indexes SharePoint content—from accessing sites on the same server farm. The crawler,
which runs on a SharePoint server, will request content to index, and the request will be denied. The crawl process will generate Access Denied events, and no content will be indexed.
The problem is solved by removing or controlling loopback checking. Details can be found in the Microsoft Knowledge Base article “You receive error 401.1 when you browse a website that uses Integrated Authentication and is hosted on IIS 5.1 or a later version” at http://support.microsoft.com/kb/896861.
The article discusses two options. Method 1 involves specifying all sites hosted on the server so that the server allows requests to those sites to originate from the same server. Method 2 entails disabling loopback checking altogether for all sites. Method 2 reduces the security of the server more than Method 1. Therefore, Method 2 is recommended only for development and test environments. Method 1 requires closely managing the servers on a SharePoint farm. Each time a new web application is added to the farm, its fully qualified host name must be added to the list of sites for which loopback checking is skipped.
PRACTICE Prepare to Install SharePoint 2010
Practices are designed to guide you through important procedures. The instructions in this Training Kit are high-level instructions that will challenge you to think carefully and to apply the procedures that are covered in this lesson and elsewhere in the Training Kit. If you need assistance, consult the detailed, step-by-step instructions in the Practice Answers on the
In this practice, you will prepare a server for installation of SharePoint Server 2010.
Prepare for the Practice
Before you perform this practice, you must ensure that your lab environment has been built according to the instructions found in the Introduction to this Training Kit.
1. Apply the snapshot SQL INSTALLED to CONTOSO-DC.
2. Apply the snapshot SQL INSTALLED to SP2010-WFE1.
3. Start CONTOSO-DC.
Wait for the virtual machine to complete startup, at which time the Press Ctrl+Alt+Del prompt appears.
4. Start SP2010-WFE1.
EXERCISE 1 Create Active Directory Accounts
In this exercise, you will create accounts for SharePoint administration, services, and access to SQL Server.
1. Log on to SP2010-WFE1 as CONTOSO\Administrator with the password Pa$$w0rd.
2. Start Active Directory Users And Computers.
3. In the Service Accounts OU, create the following user accounts. For each account, set the password to Pa$$w0rd, clear the User Must Change Password At Next Logon check box, and select the Password Never Expires check box. After creating each user, set its Description to the same value as the Full Name shown in the following table. Then set the email address of the account to UserLogonName@contoso.com—for example, SP_Admin@contoso.com.
4. Close Active Directory Users And Computers.
EXERCISE 2 Create a SQL Server Login for the SharePoint Administrator
In this exercise, you create a login and assign roles on SQL Server for the new SharePoint Administrator account.
1. Start SQL Server Management Studio and connect to SP2010-WFE1.
2. Create a login for CONTOSO\SP_Admin.
3. Assign the login the dbcreator and securityadmin server roles.
4. Close SQL Server Management Studio.
EXERCISE 3 Delegate Administration of the SharePoint Server
In this exercise, you add the SharePoint Administrator account to the local Administrators group of the SharePoint server. You will also add the user to the DnsAdmins group in the
domain, so that the SharePoint Administrator can create DNS records for web applications in the SharePoint farm.
1. Add CONTOSO\SP_Admin to the DnsAdmins group of the Contoso domain.
2. Add CONTOSO\SP_Admin to the local Administrators group of SP2010-WFE1.
3. Log off of SP2010-WFE1.
EXERCISE 4 Copy the SharePoint Installation Files to the Server
1. Log on to SP2010-WFE1 as CONTOSO\SP_Admin with the password Pa$$w0rd.
2. Copy the contents of the SharePoint Server 2010 installation media to a new folder, C:\Software\SharePoint Server 2010.
3. Share the folder with the share name SP2010. Configure share permissions to grant the Everyone group Read permission.
EXERCISE 5 Attempt to Install SharePoint Prerequisites
1. Run C:\Software\SharePoint Server 2010\default.hta.
2. Click Install SharePoint prerequisites.
The Preparation Tool reports There Was An Error During Installation.
3. Review the information provided by the Preparation Tool.
4. Review the log file. Locate the portion of the log file that documents the attempt to download the hotfix for Microsoft Windows (KB976462). Identify the URL from which the Preparation Tool attempted to download the hotfix.
The URL is http://go.microsoft.com/fwlink/?LinkID=166369. This is the URL from which you can manually download the prerequisite.
5. Close the log file and all open windows.
EXERCISE 6 Download SharePoint Prerequisites
In this exercise, you obtain the SharePoint prerequisites and save them in a shared folder.
1. Create the folder C:\Software\SharePoint Prerequisites.
2. Share the folder with the share name SP2010Prereqs. Configure share permissions to grant the Everyone group Read permission.
3. On a system with Internet connectivity, browse to http://technet.microsoft.com/en-us/library/cc262485.aspx and then download the prerequisites for SharePoint Server 2010.
4. Copy the files to the C:\Software\SharePoint Prerequisites folder.
EXERCISE 7 Create a Script for Offline Installation of Prerequisites
In this exercise, you create a PrerequisiteInstaller.Arguments.txt file that contains parameters with paths to the installation files for SharePoint prerequisites.
1. Run C:\Software\SharePoint Server 2010\PrerequisiteInstaller.exe /?.
The About window opens. Do not close the window.
2. Start Notepad.
3. Using the list of install parameters in the About window as a reference, create a script for the prerequisite installer that contains parameters for each prerequisite with the path to the installation file for that prerequisite. For example, the parameter for the installation of the Microsoft Chart Controls for Microsoft .NET Framework 3.5 is
Because you are installing SharePoint on a server running Windows Server 2008 R2, you will not need parameters for Windows Server 2008 SP2, the Microsoft .NET Framework 3.5 SP1, Windows PowerShell 2.0, or KB976394.
All parameters must be on one command line, although you can use Word Wrap in Notepad to facilitate your view of the command line.
4. Save the file as C:\Software\SharePoint Server 2010\PrerequisiteInstaller.Arguments.txt.
5. Close Notepad and the About window.
EXERCISE 8 Perform an Offline, Scripted Installation of SharePoint Prerequisites
In this exercise, you run PrerequisiteInstaller.exe with the PrerequisiteInstaller.Arguments.txt script to perform an offl ine installation of SharePoint Prerequisites.
1. Run C:\Software\SharePoint Server 2010\PrerequisiteInstaller.exe.
2. Step through the Preparation Tool to prepare the server.
3. Validate that the Preparation Tool reports Installation Complete.
If the system restarts automatically, log on as CONTOSO\SP_Admin with the password Pa$$w0rd. The Preparation Tool might open automatically after logon. If not, run
PrerequisiteInstaller.exe again. Repeat this process until the Installation Complete page appears.
If errors occur, examine the log file generated by the Preparation Tool. Verify that the PrerequisiteInstaller.Arguments.txt file contains no errors.
4. Restart SP2010-WFE1.
Prerequisite installation might continue when you log on. If so, follow the instructions provided by the Preparation Tool. If an error is reported, run the Preparation Tool one more time to determine whether the Preparation Tool can resolve the issue. Restart the system after all prerequisites have been installed successfully.
ON THE COMPANION MEDIA VERIFYING THE FILE IS CORRECT
To ensure that the file is correct, copy the PrequisiteInstaller.Arguments.txt file from the companion media (in the Practice Files\01_01 folder) to the C:\Software\SharePoint
Server 2010 folder. Then verify that the correct prerequisite installation files exist in the paths specified by each of the parameters in the PrequisiteInstaller.Arguments.txt file.