Designing A Microsoft Sharepoint 2010 Infrastructure Vol1

MCT USE ONLY.
STUDENT USE PROHIBITED
OFFICIAL
MICROSOFT
LEARNING
PRODUCT
10231A
Designing a Microsoft SharePoint 2010 Infrastructure
Be sure to access the extended learning content on your Course Companion CD enclosed on the back cover of the book.
ii
MCT USE ONLY. STUDENT USE PROHIBITED
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links may be provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission received from any linked site. Microsoft is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of Microsoft of the site or the products contained therein. 2010 Microsoft Corporation. All rights reserved. Microsoft and the trademarks listed at http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx are trademarks of the Microsoft group of companies. All other marks are property of their respective owners.
iii
Microsoft Confidential. 2010 Microsoft Corporation. All rights reserved. These materials are confidential to and maintained as a trade secret by Microsoft Corporation. Information in these materials is restricted to Microsoft authorized recipients only. These materials support a preliminary release of a product that may be changed substantially prior to final commercial release. These materials may contain preliminary information or inaccuracies, and may not correctly represent any associated Microsoft product as commercially released. All materials are provided entirely "AS IS." These materials are provided for informational purposes only and Microsoft makes no warranties, either express or implied, in these materials and assumes no liability to you for any damages of any type in connection with these materials or any intellectual property in them. The entire risk of the use or the results from the use of these materials remains with the user. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of these materials may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. By providing any feedback on these materials to Microsoft, you agree that Microsoft shall be free to use, disclose, reproduce, license, or otherwise distribute, and exploit the feedback provided to it as it sees fit, without obligation or restriction of any kind on account of intellectual property rights or otherwise.
Product Number: 10231A Part Number: 06623 Released: 09/2010
MICROSOFT LICENSE TERMS OFFICIAL MICROSOFT LEARNING PRODUCTS - TRAINER EDITION Pre-Release and Final Release Versions
These license terms are an agreement between Microsoft Corporation and you. Please read them. They apply to the Licensed Content named above, which includes the media on which you received it, if any. The terms also apply to any Microsoft updates, supplements, Internet-based services, and support services
for this Licensed Content, unless other terms accompany those items. If so, those terms apply. By using the Licensed Content, you accept these terms. If you do not accept them, do not use the Licensed Content. If you comply with these license terms, you have the rights below.
1. DEFINITIONS. a. Academic Materials means the printed or electronic documentation such as manuals,
workbooks, white papers, press releases, datasheets, and FAQs which may be included in the Licensed Content. location, an IT Academy location, or such other entity as Microsoft may designate from time to time. conducted at or through Authorized Learning Centers by a Trainer providing training to Students solely on Official Microsoft Learning Products (formerly known as Microsoft Official Curriculum or MOC) and Microsoft Dynamics Learning Products (formerly know as Microsoft Business Solutions Courseware). Each Authorized Training Session will provide training on the subject matter of one (1) Course. Center during an Authorized Training Session, each of which provides training on a particular Microsoft technology subject matter.
b. Authorized Learning Center(s) means a Microsoft Certified Partner for Learning Solutions
c. Authorized Training Session(s) means those training sessions authorized by Microsoft and
d. Course means one of the courses using Licensed Content offered by an Authorized Learning
e. Device(s) means a single computer, device, workstation, terminal, or other digital electronic or
analog device.
f.
Licensed Content means the materials accompanying these license terms. The Licensed Content may include, but is not limited to, the following elements: (i) Trainer Content, (ii) Student Content, (iii) classroom setup guide, and (iv) Software. There are different and separate components of the Licensed Content for each Course. Software means the Virtual Machines and Virtual Hard Disks, or other software applications that may be included with the Licensed Content.
g.
h. Student(s) means a student duly enrolled for an Authorized Training Session at your location.
i.
Student Content means the learning materials accompanying these license terms that are for use by Students and Trainers during an Authorized Training Session. Student Content may include labs, simulations, and courseware files for a Course. Trainer(s) means a) a person who is duly certified by Microsoft as a Microsoft Certified Trainer and b) such other individual as authorized in writing by Microsoft and has been engaged by an Authorized Learning Center to teach or instruct an Authorized Training Session to Students on its behalf. Trainers and Students, as applicable, solely during an Authorized Training Session. Trainer Content may include Virtual Machines, Virtual Hard Disks, Microsoft PowerPoint files, instructor notes, and demonstration guides and script files for a Course. Virtual Hard Disks means Microsoft Software that is comprised of virtualized hard disks (such as a base virtual hard disk or differencing disks) for a Virtual Machine that can be loaded onto a single computer or other device in order to allow end-users to run multiple operating systems concurrently. For the purposes of these license terms, Virtual Hard Disks will be considered Trainer Content. Microsoft Virtual PC or Microsoft Virtual Server software that consists of a virtualized hardware environment, one or more Virtual Hard Disks, and a configuration file setting the parameters of the virtualized hardware environment (e.g., RAM). For the purposes of these license terms, Virtual Hard Disks will be considered Trainer Content. you means the Authorized Learning Center or Trainer, as applicable, that has agreed to these license terms.
j.
k. Trainer Content means the materials accompanying these license terms that are for use by
l.
m. Virtual Machine means a virtualized computing experience, created and accessed using
n.
2. OVERVIEW.
Licensed Content. The Licensed Content includes Software, Academic Materials (online and electronic), Trainer Content, Student Content, classroom setup guide, and associated media. License Model. The Licensed Content is licensed on a per copy per Authorized Learning Center location or per Trainer basis.
3. INSTALLATION AND USE RIGHTS. a. Authorized Learning Centers and Trainers: For each Authorized Training Session, you
may: i. either install individual copies of the relevant Licensed Content on classroom Devices only for use by Students enrolled in and the Trainer delivering the Authorized Training Session, provided that the number of copies in use does not exceed the number of Students enrolled in and the Trainer delivering the Authorized Training Session, OR
ii. install one copy of the relevant Licensed Content on a network server only for access by classroom Devices and only for use by Students enrolled in and the Trainer delivering the Authorized Training Session, provided that the number of Devices accessing the Licensed Content on such server does not exceed the number of Students enrolled in and the Trainer delivering the Authorized Training Session. iii. and allow the Students enrolled in and the Trainer delivering the Authorized Training Session to use the Licensed Content that you install in accordance with (ii) or (ii) above during such Authorized Training Session in accordance with these license terms.
i.
Separation of Components. The components of the Licensed Content are licensed as a single unit. You may not separate the components and install them on different Devices.
ii. Third Party Programs. The Licensed Content may contain third party programs. These license terms will apply to the use of those third party programs, unless other terms accompany those programs.
b. Trainers:
i. Trainers may Use the Licensed Content that you install or that is installed by an Authorized Learning Center on a classroom Device to deliver an Authorized Training Session.
ii. Trainers may also Use a copy of the Licensed Content as follows:
A. Licensed Device. The licensed Device is the Device on which you Use the Licensed Content.
You may install and Use one copy of the Licensed Content on the licensed Device solely for your own personal training Use and for preparation of an Authorized Training Session. personal training Use and for preparation of an Authorized Training Session.
B. Portable Device. You may install another copy on a portable device solely for your own 4. PRE-RELEASE VERSIONS. If this is a pre-release (beta) version, in addition to the other provisions
in this agreement, these terms also apply:
a. Pre-Release Licensed Content. This Licensed Content is a pre-release version. It may not
contain the same information and/or work the way a final version of the Licensed Content will. We may change it for the final, commercial version. We also may not release a commercial version. You will clearly and conspicuously inform any Students who participate in each Authorized Training Session of the foregoing; and, that you or Microsoft are under no obligation to provide them with any further content, including but not limited to the final released version of the Licensed Content for the Course. Microsoft, without charge, the right to use, share and commercialize your feedback in any way and for any purpose. You also give to third parties, without charge, any patent rights needed for their products, technologies and services to use or interface with any specific parts of a Microsoft software, Licensed Content, or service that includes the feedback. You will not give feedback that is subject to a license that requires Microsoft to license its software or documentation to third parties because we include your feedback in them. These rights survive this agreement.
b. Feedback. If you agree to give feedback about the Licensed Content to Microsoft, you give to
c. Confidential Information. The Licensed Content, including any viewer, user interface, features
and documentation that may be included with the Licensed Content, is confidential and proprietary to Microsoft and its suppliers. i. Use. For five years after installation of the Licensed Content or its commercial release, whichever is first, you may not disclose confidential information to third parties. You may disclose confidential information only to your employees and consultants who need to know the information. You must have written agreements with them that protect the confidential information at least as much as this agreement. Survival. Your duty to protect confidential information survives this agreement.
ii.
iii. Exclusions. You may disclose confidential information in response to a judicial or governmental order. You must first give written notice to Microsoft to allow it to seek a
protective order or otherwise protect the information. Confidential information does not include information that d. becomes publicly known through no wrongful act; you received from a third party who did not breach confidentiality obligations to Microsoft or its suppliers; or you developed independently.
Term. The term of this agreement for pre-release versions is (i) the date which Microsoft informs you is the end date for using the beta version, or (ii) the commercial release of the final release version of the Licensed Content, whichever is first (beta term). Use. You will cease using all copies of the beta version upon expiration or termination of the beta term, and will destroy all copies of same in the possession or under your control and/or in the possession or under the control of any Trainers who have received copies of the pre-released version. Copies. Microsoft will inform Authorized Learning Centers if they may make copies of the beta version (in either print and/or CD version) and distribute such copies to Students and/or Trainers. If Microsoft allows such distribution, you will follow any additional terms that Microsoft provides to you for such copies and distribution.
e.
f.
5. ADDITIONAL LICENSING REQUIREMENTS AND/OR USE RIGHTS.

a. Authorized Learning Centers and Trainers: i. Software.
ii. Virtual Hard Disks. The Licensed Content may contain versions of Microsoft XP, Microsoft Windows Vista, Windows Server 2003, Windows Server 2008, and Windows 2000 Advanced Server and/or other Microsoft products which are provided in Virtual Hard Disks. A. If the Virtual Hard Disks and the labs are launched through the Microsoft Learning Lab Launcher, then these terms apply: Time-Sensitive Software. If the Software is not reset, it will stop running based upon the time indicated on the install of the Virtual Machines (between 30 and 500 days after you install it). You will not receive notice before it stops running. You may not be able to access data used or information saved with the Virtual Machines when it stops running and may be forced to reset these Virtual Machines to their original state. You must remove the Software from the Devices at the end of each Authorized Training Session and reinstall and launch it prior to the beginning of the next Authorized Training Session. B. If the Virtual Hard Disks require a product key to launch, then these terms apply: Microsoft will deactivate the operating system associated with each Virtual Hard Disk. Before installing any Virtual Hard Disks on classroom Devices for use during an Authorized Training Session, you will obtain from Microsoft a product key for the operating system software for the Virtual Hard Disks and will activate such Software with Microsoft using such product key. C. These terms apply to all Virtual Machines and Virtual Hard Disks:
You may only use the Virtual Machines and Virtual Hard Disks if you comply with the terms and conditions of this agreement and the following security requirements: o o You may not install Virtual Machines and Virtual Hard Disks on portable Devices or Devices that are accessible to other networks. You must remove Virtual Machines and Virtual Hard Disks from all classroom Devices at the end of each Authorized Training Session, except those held at Microsoft Certified Partners for Learning Solutions locations. You must remove the differencing drive portions of the Virtual Hard Disks from all classroom Devices at the end of each Authorized Training Session at Microsoft Certified Partners for Learning Solutions locations. You will ensure that the Virtual Machines and Virtual Hard Disks are not copied or downloaded from Devices on which you installed them. You will strictly comply with all Microsoft instructions relating to installation, use, activation and deactivation, and security of Virtual Machines and Virtual Hard Disks. You may not modify the Virtual Machines and Virtual Hard Disks or any contents thereof. You may not reproduce or redistribute the Virtual Machines or Virtual Hard Disks.
o o o o
ii. Classroom Setup Guide. You will assure any Licensed Content installed for use during an
Authorized Training Session will be done in accordance with the classroom set-up guide for the Course. iii. Media Elements and Templates. You may allow Trainers and Students to use images, clip art, animations, sounds, music, shapes, video clips and templates provided with the Licensed Content solely in an Authorized Training Session. If Trainers have their own copy of the Licensed Content, they may use Media Elements for their personal training use. iv. iv Evaluation Software. Any Software that is included in the Student Content designated as Evaluation Software may be used by Students solely for their personal training outside of the Authorized Training Session.
b. Trainers Only:
i. Use of PowerPoint Slide Deck Templates. The Trainer Content may include Microsoft PowerPoint slide decks. Trainers may use, copy and modify the PowerPoint slide decks only for providing an Authorized Training Session. If you elect to exercise the foregoing, you will agree or ensure Trainer agrees: (a) that modification of the slide decks will not constitute creation of obscene or scandalous works, as defined by federal law at the time the work is created; and (b) to comply with all other terms and conditions of this agreement.
ii. Use of Instructional Components in Trainer Content. For each Authorized Training Session, Trainers may customize and reproduce, in accordance with the MCT Agreement, those portions of the Licensed Content that are logically associated with instruction of the Authorized Training Session. If you elect to exercise the foregoing rights, you agree or ensure the Trainer agrees: (a) that any of these customizations or reproductions will only be used for providing an Authorized Training Session and (b) to comply with all other terms and conditions of this agreement.
iii. Academic Materials. If the Licensed Content contains Academic Materials, you may copy and use the Academic Materials. You may not make any modifications to the Academic Materials and you may not print any book (either electronic or print version) in its entirety. If you reproduce any Academic Materials, you agree that:
The use of the Academic Materials will be only for your personal reference or training use You will not republish or post the Academic Materials on any network computer or broadcast in any media; You will include the Academic Materials original copyright notice, or a copyright notice to Microsofts benefit in the format provided below: Form of Notice: 2010 Reprinted for personal reference use only with permission by Microsoft Corporation. All rights reserved. Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the US and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.
6. INTERNET-BASED SERVICES. Microsoft may provide Internet-based services with the Licensed
Content. It may change or cancel them at any time. You may not use these services in any way that could harm them or impair anyone elses use of them. You may not use the services to try to gain unauthorized access to any service, data, account or network by any means.
7. SCOPE OF LICENSE. The Licensed Content is licensed, not sold. This agreement only gives you some
rights to use the Licensed Content. Microsoft reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the Licensed Content only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the Licensed Content that only allow you to use it in certain ways. You may not install more copies of the Licensed Content on classroom Devices than the number of Students and the Trainer in the Authorized Training Session; allow more classroom Devices to access the server than the number of Students enrolled in and the Trainer delivering the Authorized Training Session if the Licensed Content is installed on a network server; copy or reproduce the Licensed Content to any server or location for further reproduction or distribution; disclose the results of any benchmark tests of the Licensed Content to any third party without Microsofts prior written approval; work around any technical limitations in the Licensed Content; reverse engineer, decompile or disassemble the Licensed Content, except and only to the extent that applicable law expressly permits, despite this limitation; make more copies of the Licensed Content than specified in this agreement or allowed by applicable law, despite this limitation; publish the Licensed Content for others to copy;
transfer the Licensed Content, in whole or in part, to a third party; access or use any Licensed Content for which you (i) are not providing a Course and/or (ii) have not been authorized by Microsoft to access and use; rent, lease or lend the Licensed Content; or use the Licensed Content for commercial hosting services or general business purposes. Rights to access the server software that may be included with the Licensed Content, including the Virtual Hard Disks does not give you any right to implement Microsoft patents or other Microsoft intellectual property in software or devices that may access the server.
8. EXPORT RESTRICTIONS. The Licensed Content is subject to United States export laws and
regulations. You must comply with all domestic and international export laws and regulations that apply to the Licensed Content. These laws include restrictions on destinations, end users and end use. For additional information, see www.microsoft.com/exporting. Content marked as NFR or Not for Resale.
9. NOT FOR RESALE SOFTWARE/LICENSED CONTENT. You may not sell software or Licensed 10. ACADEMIC EDITION. You must be a Qualified Educational User to use Licensed Content marked as
Academic Edition or AE. If you do not know whether you are a Qualified Educational User, visit www.microsoft.com/education or contact the Microsoft affiliate serving your country. fail to comply with the terms and conditions of these license terms. In the event your status as an Authorized Learning Center or Trainer a) expires, b) is voluntarily terminated by you, and/or c) is terminated by Microsoft, this agreement shall automatically terminate. Upon any termination of this agreement, you must destroy all copies of the Licensed Content and all of its component parts.
11. TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you
12. ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates, Internet-
based services and support services that you use, are the entire agreement for the Licensed Content and support services.
13. APPLICABLE LAW. a. United States. If you acquired the Licensed Content in the United States, Washington state law
governs the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws principles. The laws of the state where you live govern all other claims, including claims under state consumer protection laws, unfair competition laws, and in tort.
b. Outside the United States. If you acquired the Licensed Content in any other country, the laws
of that country apply.
14. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the
laws of your country. You may also have rights with respect to the party from whom you acquired the Licensed Content. This agreement does not change your rights under the laws of your country if the laws of your country do not permit it to do so.
15. DISCLAIMER OF WARRANTY. The Licensed Content is licensed as-is. You bear the risk of
using it. Microsoft gives no express warranties, guarantees or conditions. You may have additional consumer rights under your local laws which this agreement cannot change. To the extent permitted under your local laws, Microsoft excludes the implied warranties of merchantability, fitness for a particular purpose and non-infringement.
16. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. YOU CAN RECOVER FROM
MICROSOFT AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP TO U.S. $5.00. YOU CANNOT RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES. This limitation applies to anything related to the Licensed Content, software, services, content (including code) on third party Internet sites, or third party programs; and claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence, or other tort to the extent permitted by applicable law.
It also applies even if Microsoft knew or should have known about the possibility of the damages. The above limitation or exclusion may not apply to you because your country may not allow the exclusion or limitation of incidental, consequential or other damages. Please note: As this Licensed Content is distributed in Quebec, Canada, some of the clauses in this agreement are provided below in French. Remarque : Ce le contenu sous licence tant distribu au Qubec, Canada, certaines des clauses dans ce contrat sont fournies ci-dessous en franais. EXONRATION DE GARANTIE. Le contenu sous licence vis par une licence est offert tel quel . Toute utilisation de ce contenu sous licence est votre seule risque et pril. Microsoft naccorde aucune autre garantie expresse. Vous pouvez bnficier de droits additionnels en vertu du droit local sur la protection dues consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les garanties implicites de qualit marchande, dadquation un usage particulier et dabsence de contrefaon sont exclues. LIMITATION DES DOMMAGES-INTRTS ET EXCLUSION DE RESPONSABILIT POUR LES DOMMAGES. Vous pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages directs uniquement hauteur de 5,00 $ US. Vous ne pouvez prtendre aucune indemnisation pour les autres dommages, y compris les dommages spciaux, indirects ou accessoires et pertes de bnfices. Cette limitation concerne: tout ce qui est reli au le contenu sous licence , aux services ou au contenu (y compris le code) figurant sur des sites Internet tiers ou dans des programmes tiers ; et les rclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilit stricte, de ngligence ou dune autre faute dans la limite autorise par la loi en vigueur.
Elle sapplique galement, mme si Microsoft connaissait ou devrait connatre lventualit dun tel dommage. Si votre pays nautorise pas lexclusion ou la limitation de responsabilit pour les dommages indirects, accessoires ou de quelque nature que ce soit, il se peut que la limitation ou lexclusion ci-dessus ne sappliquera pas votre gard. EFFET JURIDIQUE. Le prsent contrat dcrit certains droits juridiques. Vous pourriez avoir dautres droits prvus par les lois de votre pays. Le prsent contrat ne modifie pas les droits que vous confrent les lois de votre pays si celles-ci ne le permettent pas.
Welcome!
Thank you for taking our training! Weve worked together with our Microsoft Certied Partners for Learning Solutions and our Microsoft IT Academies to bring you a world-class learning experiencewhether youre a professional looking to advance your skills or a student preparing for a career in IT.
n
Microsoft Certied Trainers and InstructorsYour instructor is a technical and instructional expert who meets ongoing certication requirements. And, if instructors are delivering training at one of our Certied Partners for Learning Solutions, they are also evaluated throughout the year by students and by Microsoft. Certication Exam BenetsAfter training, consider taking a Microsoft Certication exam. Microsoft Certications validate your skills on Microsoft technologies and can help differentiate you when finding a job or boosting your career. In fact, independent research by IDC concluded that 75% of managers believe certications are important to team performance1. Ask your instructor about Microsoft Certication exam promotions and discounts that may be available to you.
n Customer Satisfaction GuaranteeOur Certied Partners for Learning Solutions offer a satisfaction guarantee and we hold them accountable for it. At the end of class, please complete an evaluation of todays experience. We value your feedback!
We wish you a great learning experience and ongoing success in your career!
Sincerely, Microsoft Learning www.microsoft.com/learning
IDC, Value of Certication: Team Certication and Organizational Performance, November 2006
iv
Acknowledgement
Microsoft Learning would like to acknowledge and thank the following for their contribution towards developing this title. Their effort at various stages in the development has ensured that you have a good classroom experience.
John Devaney Content Developer

John is a Principle Technologist at CM Group and has worked in IT training and content development for over 15 years. He has worked with collaboration platforms and WCM since the mid-nineties and first worked on SharePoint with SharePoint Portal Server 2003. He was part of the team who developed the Microsoft Office SharePoint Server 2007 curriculum. In addition to content development, John works as a consultant on a SharePoint and educational development across a range of industries and technologies.
James Hamilton-Adams Content Developer

James has been a trainer and consultant on Microsoft technologies for nearly 10 years, and is an associate technologist with CM Group. James specializes in Microsoft Exchange Server, SharePoint Server, and Project Server, for which he holds both MCTS and MCITP certifications. James has been working with SharePoint since the first release in 2001, and regularly works with organizations to assist with SharePoint integration into collaborative business processes.
Rose Malcolm Content Developer

Rose is a Senior Technologist with CM Group and has been a trainer and writer on Microsoft technologies for nearly 12 years. She has written technical documentation, including security guides, whitepapers and e-Learning courseware, along with several ILT courses for Microsoft Learning. Rose recently co-authored the Microsoft Office SharePoint Server 2010 Hands-On Labs for the SharePoint Product Group.
Steve Ryan Content Developer

Steve is a Senior Technologist with CM Group. He is an MCITP Server Administrator and a MCTS in Office SharePoint Server 2007, Active Directory, Network Infrastructure, and Applications Infrastructure configuration. He has authored several ILT courses for Microsoft Learning. He has also written technical documentation, including security guides, whitepapers and e-Learning courseware. He has authored the 'Administrator Accounts Security Planning', and 'Services and Service Accounts Security Planning' guides for Microsoft. He co-authored the Microsoft Office SharePoint Server 2010 Hands-On Labs for the SharePoint
Product Group and also authored the 50213A - Implementing Data Protection Manager 2007 ILT and e-Learning courses.
Scott Jamison - Subject Matter Expert

Scott Jamison (Microsoft Certified Master) is managing partner at Jornata LLC, a Boston-based SharePoint consulting firm. He has over 20 years experience designing and developing solutions using Microsoft technologies. Scott has designed courseware for the SharePoint 2007 and 2010 Master Certifications and is the author of several books, including Essential SharePoint 2007 and Essential SharePoint 2010
Donal Conlon - Subject Matter Expert

Donal Conlon is a principal consultant at Jornata LLC, a Boston-based SharePoint consulting firm. He has over 15 years experience designing and developing solutions using Microsoft technologies. Donal has been working with SharePoint for over 8 years and is a contributing author of Essential SharePoint 2010.
Peter Serzo Technical Reviewer

Peter (MCP, MCPD, MCTS) has been consulting in technology for over 20 years. Peter started his career working for Ross Perot's EDS programming in COBOL for EDI and Electronic Commerce systems. He is currently a SharePoint Architect consultant for Trillium Teamologies Inc. in Royal Oak, MI. His strength is in understanding a myriad of business processes and melding them with a proper SharePoint solution. With a major in English and a strong background in mainframes to PCs, he brings a unique perspective to infrastructure and processes that cannot be taught.
vi
Contents
Module 1: Designing a Logical Architecture
Lesson 1: Identifying Business Requirements Lesson 2: Overview of SharePoint 2010 Logical Architecture Lesson 3: Documenting Your SharePoint 2010 Environment Lesson 4: Documenting the Logical Architecture Lab: Designing a Logical Architecture 1-4 1-22 1-31 1-37 1-46
Module 2: Planning a Service Application Architecture

Lesson 1: Introduction to the Service Application Architecture in SharePoint 2010 Lesson 2: Service Application Architecture and Components Lesson 3: Topologies for Service Applications Lesson 4: Mapping Service Applications to Your Logical Architecture Lab: Planning a Service Application Architecture 2-4 2-18 2-31 2-43 2-50
Module 3: Planning for Performance and Capacity

Lesson 1: Principles of Performance Planning Lesson 2: Designing for Performance Lesson 3: Principles of Capacity Planning Lesson 4: Designing for Capacity Lab: Planning for Performance and Capacity 3-3 3-17 3-41 3-52 3-65
Module 4: Designing a Physical Architecture

Lesson 1: Designing Physical Components for SharePoint Deployments Lesson 2: Designing Supporting Components for SharePoint Deployments Lesson 3: Topologies for Model Design Lesson 4: Mapping a Logical Architecture Design to a Physical Architecture Design Lab: Designing a Physical Architecture 4-4 4-20 4-27 4-37 4-47
vii
Module 5: Designing a Security Plan

Lesson 1: Designing Security for SharePoint 2010 Lesson 2: Planning for Service Accounts Lesson 3: Planning for User and Group Security Lesson 4: Planning for SSL Lab: Designing a Security Plan 5-3 5-8 5-18 5-32 5-36
Module 6: Planning Authentication

Lesson 1: Overview of Authentication Lesson 2: Introduction to Claims-Based Authentication Lesson 3: Selecting Authentication Methods Lab: Planning Authentication 6-3 6-16 6-25 6-36
Module 7: Planning Managed Metadata

Lesson 1: Metadata in SharePoint 2010 Lesson 2: Overview of Content Types Lesson 3: Mapping Managed Metadata to Business Requirements Lab: Planning Managed Metadata 7-4 7-16 7-26 7-36
Module 8: Planning Social Computing

Lesson 1: Overview of Social Computing 8-3 Lesson 2: Planning for Social Computing Functionality in SharePoint 2010 8-14 Lesson 3: Planning for the User Profile Service 8-37 Lab: Planning Social Computing 8-54
Module 9: Designing an Enterprise Search Strategy

Lesson 1: Overview of SharePoint 2010 Search Architecture Lesson 2: Search Topologies in SharePoint 2010 Lesson 3: Capacity and Performance Planning for Search Lesson 4: Mapping Business Requirements to Search Design Lab: Designing an Enterprise Search Strategy 9-4 9-19 9-28 9-40 9-51
viii
Module 10: Planning Enterprise Content Management

Lesson 1: Overview of Enterprise Content Management Lesson 2: Planning Processes for Content Management Lesson 3: Planning Features and Policies for Content Management Lesson 4: Planning Web Content Management Lab: Planning Enterprise Content Management 10-4 10-14 10-26 10-46 10-59
Module 11: Planning a SharePoint 2010 Implementation of a Business Intelligence Strategy

Lesson 1: Overview of Business Intelligence Principles Lesson 2: Planning Data Access Using BCS Lesson 3: Planning SharePoint 2010 Business Intelligence Solutions Lesson 4: Planning for Reporting and Presentation Lab: Planning a SharePoint 2010 Implementation of a Business Intelligence Strategy 11-4 11-14 11-26 11-44 11-51
Module 12: Developing a Plan for Governance

Lesson 1: Overview of Governance 12-4 Lesson 2: Key Elements of a Governance Plan 12-13 Lesson 3: Planning for Governance in SharePoint Server 2010 12-27 Lesson 4: Governance Implementation Features and Policies in SharePoint Server 2010 12-38 Lab: Developing a Plan for Governance 12-51
Module 13: Designing a Maintenance and Monitoring Plan

Lesson 1: Principles of Maintenance and Monitoring Lesson 2: Creating a Maintenance Plan for SharePoint 2010 Lesson 3: Creating a Monitoring Plan for SharePoint 2010 Lesson 4: Considerations for the Maintenance and Monitoring of Associated Technologies Lab: Designing a Maintenance and Monitoring Plan 13-3 13-11 13-23 13-35 13-46
ix
Module 14: Planning Business Continuity

Lesson 1: Overview of Business Continuity Management Lesson 2: Developing a Business Continuity Plan for SharePoint Server 2010 Lesson 3: Creating a Backup and Restore Plan for SharePoint Server 2010 Lab: Planning Business Continuity 14-4 14-15 14-34 14-47
Module 15: Planning for Upgrading to SharePoint 2010

Lesson 1: Identifying Upgrade Scenarios Lesson 2: Planning Your Upgrade Lesson 3: Upgrade Considerations Lab: Planning for Upgrading to SharePoint 2010 15-4 15-23 15-42 15-57
Appendix: Lab Answer Keys

Module 1 Lab: Designing a Logical Architecture Module 2 Lab: Planning a Service Application Architecture Module 3 Lab: Planning for Performance and Capacity Module 4 Lab: Designing a Physical Architecture Module 5 Lab: Designing a Security Plan Module 6 Lab: Planning Authentication Module 7 Lab: Planning Managed Metadata Module 8 Lab: Planning Social Computing Module 9 Lab: Designing an Enterprise Search Strategy Module 10 Lab: Planning Enterprise Content Management Module 11 Lab: Planning a SharePoint 2010 Implementation of a Business Intelligence Strategy Module 12 Lab: Developing a Plan for Governance Module 13 Lab: Designing a Maintenance and Monitoring Plan Module 14 Lab: Planning Business Continuity Module 15 Lab: Planning for Upgrading to SharePoint 2010 L1-1 L2-1 L3-1 L4-1 L5-1 L6-1 L7-1 L8-1 L9-1 L10-1 L11-1 L12-1 L13-1 L14-1 L15-1
About This Course
About This Course

This section provides you with a brief description of the course, audience, suggested prerequisites, and course objectives.
Course Description
This five-day course focuses on how to design a Microsoft SharePoint 2010 infrastructure for solution architects. The course discusses the key planning elements that you must plan to deploy a robust SharePoint 2010 solution, including logical and physical design. You will see how to plan for specific SharePoint 2010 infrastructure components, such as service applications and managed metadata. You will also see how to plan business solutions, including search and business intelligence (BI). The course includes planning advice for both new deployments and upgrades from previous versions of Microsoft Office SharePoint.
Audience
This course is intended for IT professionals who use Microsoft SharePoint 2010 in a team-based, medium-sized to large environment. Although they may have implemented a Microsoft Office SharePoint deployment, they have limited experience of designing a SharePoint 2010 infrastructure. A typical student will probably work as a senior administrator who acts as a technical lead over a team of administrators. Members of this audience should have at least six months of experience with SharePoint 2010 (including prereleased versions of the product).
Student Prerequisites
This course requires that you meet the following prerequisites: Experience of deployment and management of Microsoft Office SharePoint architectures and solutions. Proficiency with Internet Information Services (IIS) version 7, Domain Name System (DNS), the Active Directory directory service, and Microsoft SQL Server 2005 or Microsoft SQL Server 2008, because these technologies relate to SharePoint 2010. Proficiency with the infrastructure and security of Windows Server 2008. Experience of business operations for IT, including data backup, restoration, and high availability. Experience of Windows PowerShell 2.0 and command-line administration.
ii
About This Course
Experience of server availability and performance concepts (SQL Server mirroring and load balancing). A good understanding of security concepts and authentication methods, including least privilege, as they relate to Microsoft Office SharePoint. An understanding of Internet Security and Acceleration (ISA) Server and Microsoft Forefront Unified Access Gateway (UAG). Experience of designing for high availability and disaster recovery. A conceptual understanding of BI, search, and the use of metadata.
Course Objectives
After completing this course, students will be able to: Describe the core methods for identifying business requirements and how these affect logical architecture planning for a SharePoint 2010 deployment. Describe how to plan the service application architecture in SharePoint 2010. Describe the principles of designing to maximize performance and capacity in a SharePoint 2010 deployment. Describe how to successfully plan the physical components of a SharePoint 2010 deployment. Describe the security architecture of SharePoint 2010 and the importance of creating a design that is based on the principle of least privilege. Explain how to select authentication methods in a SharePoint 2010 design. Describe how to match the managed metadata architecture in SharePoint 2010 to business requirements. Describe how to plan a social computing implementation of SharePoint 2010 that meets business requirements. Describe the architecture and topologies that are available to service a range of search requirements across business models. Describe the core functionality of Enterprise Content Management (ECM) in SharePoint 2010 and how it influences solution design. Describe core BI principles that will affect planning for SharePoint 2010. Describe how to plan for data governance in SharePoint 2010.
About This Course
iii
Describe the considerations for developing a maintenance and monitoring plan for SharePoint 2010 that also incorporates the technologies that support SharePoint 2010. Describe how to develop a business continuity plan for SharePoint 2010. Describe the available options and their benefits when you plan a Microsoft Office SharePoint upgrade to SharePoint 2010.
Course Outline
This section provides an outline of the course: Module 1, Designing a Logical Architecture, describes the function, components, and creation of a logical design and explains why this design is the first stage in any SharePoint 2010 solution. Module 2, Planning a Service Application Architecture, describes the new service application architecture in SharePoint 2010 and explains how you should plan to deploy services across a range of farm topologies. Module 3, Planning for Performance and Capacity, explains the importance of performance and capacity planning in SharePoint 2010. It also describes how to design a robust and high-performance deployment. Module 4, Designing a Physical Architecture, describes the key components of the physical architecture in SharePoint 2010, such as processor, memory, disk, and network access. It reviews how best to design a hardware and software infrastructure for each of the server types that you can deploy in a SharePoint farm. Module 5, Designing a Security Plan, describes the security architecture of SharePoint 2010 and the considerations that you must include in your security planning. These considerations include management of security accounts, management of users and groups, and the reasons why you should implement secure transport protocols. Module 6, Planning Authentication, discusses the available authentication options for SharePoint 2010 and describes how to plan for these in the new, claims-based security architecture. Module 7, Planning Managed Metadata, describes the function of managed metadata and explains how you can best use the Managed Metadata Service to deliver business benefits. Module 8, Planning Social Computing, explains how SharePoint 2010 can deliver social computing services to an organization. It focuses particularly on the
iv
About This Course
planning that you require to deploy the User Profile Service to maximize social computing benefits. Module 9, Designing an Enterprise Search Strategy, describes the architectures and topologies that are available when you plan to deploy enterprise search in your organization. This includes discussions about both SharePoint 2010 search and Microsoft FAST Search Server 2010 for SharePoint. Module 10, Planning Enterprise Content Management, explains how the core ECM functionality in SharePoint 2010 may influence your document and records management design. It also focuses on the planning for enterprise Web content management. Module 11, Planning a SharePoint 2010 Implementation of a Business Intelligence Strategy, explains how you can integrate BI functionality in SharePoint 2010 into an overall enterprise BI strategy. Module 12, Developing a Plan for Governance, describes the concepts that are associated with corporate governance for SharePoint 2010. Based on this knowledge, the module helps you to plan for governance in a SharePoint 2010 farm. Module 13, Designing a Maintenance and Monitoring Plan, describes the essential principles of maintenance and monitoring and maps these against the functionality that is available in SharePoint 2010. It then uses this framework to identify how best to develop a maintenance and monitoring plan for SharePoint 2010. Module 14, Planning Business Continuity, describes the components of an effective business continuity plan. It also explains how to map functionality and components in SharePoint 2010 against business requirements for different business continuity metrics. Module 15, Planning for Upgrade to SharePoint 2010, reviews the options for performing an upgrade to SharePoint 2010 from a range of previous versions. It also outlines the milestones that are necessary to develop a successful upgrade plan.
About This Course
Course Materials
The following materials are included with your kit: Course Handbook. A succinct classroom learning guide that provides all the critical technical information in a crisp, tightly-focused format, which is just right for an effective in-class learning experience. Lessons: Guide you through the learning objectives and provide the key points that are critical to the success of the in-class learning experience. Labs: Provide a real-world, hands-on platform for you to apply the knowledge and skills learned in the module. Module Reviews and Takeaways: Provide improved on-the-job reference material to boost knowledge and skills retention. Lab Answer Keys: Provide step-by-step lab solution guidance at your finger tips when its needed.
Course Companion CD. Searchable, easy-to-navigate digital content with integrated premium on-line resources designed to supplement the Course Handbook. Lessons: Include Course Handbook content along with additional information and resources, such as detailed demo steps, code samples, answers to questions, and links to up-to-date premium content on TechNet, MSDN, etc. Labs: Include complete lab exercise information and answer keys in digital form to use during lab time. Resources: Include well-categorized additional resources that give you immediate access to the most up-to-date premium content on TechNet, MSDN, and Microsoft Press. Student Course Files: Include the Allfiles.exe, a self-extracting executable file that contains all the files required for the labs and demonstrations.
Note: To access the full course content, insert the Course Companion CD into the CDROM drive, and then in the root directory of the CD, double-click StartCD.exe.
Course evaluation. At the end of the course, you will have the opportunity to complete an online evaluation to provide feedback on the course, training facility, and instructor.
vi
About This Course
To provide additional comments or feedback on the course, send e-mail to support@mscourseware.com. To inquire about the Microsoft Certification Program, send e-mail to mcphelp@microsoft.com.
About This Course
vii
Virtual Machine Environment

This section provides the information for setting up the classroom environment to support the business scenario of the course.
Virtual Machine Configuration

In this course, you will use M Hyper-V to perform the labs. Each classroom computer serves as a host for one virtual machine that will run in Hyper-V. There is one Hyper-V virtual machine for each lab in this course, named 10231A-NYC-DC1XX. Each virtual machine has an internal computer name of 10231A-NYC-DC1
Important: At the end of each lab, you must close the virtual machine and must not save any changes.
The following table shows the role of each virtual machine used in this course:
Virtual machine 10231A-NYC-DC1-01 Role Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008
10231A-NYC-DC1-02
10231A-NYC-DC1-03
10231A-NYC-DC1-04
10231A-NYC-DC1-05
10231A-NYC-DC1-06
10231A-NYC-DC1-07
10231A-NYC-DC1-08
viii
About This Course
Virtual machine 10231A-NYC-DC1-09
Role Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008 Domain controller, Microsoft SharePoint 2010 server, and computer running SQL Server 2008
10231A-NYC-DC1-10
10231A-NYC-DC1-11
10231A-NYC-DC1-12
10231A-NYC-DC1-13
10231A-NYC-DC1-14
10231A-NYC-DC1-15
Software Configuration
The following software is installed on each virtual machine (VM): Windows Server 2008 SharePoint Server 2010 SQL Server 2008 R2 Microsoft Office 2010 Microsoft Visio 2010
Course Files
There are files associated with the labs in this course. The lab files are located in the folder E:\Labfiles on the student computers.
About This Course
ix
Classroom Setup
Each classroom computer will have the same VM, configured in the same way. The VM is configured as a domain controller and has SharePoint 2010 installed in the default Web site. Additionally, each VM has installations of Microsoft Office 2010 and Microsoft Visio 2010, which students will use in the planning exercises.
Course Hardware Level

To ensure a satisfactory student experience, Microsoft Learning requires a minimum equipment configuration for trainer and student computers in all Microsoft Certified Partner for Learning Solutions (CPLS) classrooms in which Official Microsoft Learning Product courseware are taught. The course requires that you have a computer that meets or exceeds hardware level 6, which prescribes the following: Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) 64bit processor. Dual 120-GB hard disks, 7,200 RAM Serial Advanced Technology Attachment (SATA) or better (configured as a stripe array). 4 GB of RAM expandable to 8 GB or higher (recommended). DVD drive. Network adapter. Super VGA (SVGA) 17-inch monitor. Microsoft mouse or compatible pointing device. Sound card with amplified speakers.
In addition, the instructor computer must be connected to a projection display device that supports SVGA 1024 768, 16-bit colors.
Designing a Logical Architecture
1-1
Module 1
Contents:
Lesson 1: Identifying Business Requirements Lesson 2: Overview of SharePoint 2010 Logical Architecture Lesson 3: Documenting Your SharePoint 2010 Environment Lesson 4: Documenting the Logical Architecture Lab: Designing a Logical Architecture 1-4 1-22 1-31 1-37 1-46
1-2
Module Overview
This module discusses the importance of using the Microsoft SharePoint 2010 products to create a logical architecture design based on business requirements before you implement a solution. The module covers conceptual content, defining a logical architecture, and the components of SharePoint 2010 that you must map to business specifications. Requirements gathering, and the development of a solution design, are a complex area of study. There is a range of structured methods for identifying, analyzing, and documenting systems and business processes. This module reviews some of the techniques for analyzing and designing business solutions for SharePoint 2010, rather than any specific structured methodology.
Objectives
After completing this module, you will be able to: Identify business requirements and describe how business requirements affect the logical architecture of a SharePoint 2010 deployment.
1-3
Map business requirements to SharePoint 2010 architecture components. Explain the importance of documentation and describe the options for documenting logical architecture. Describe how to document a logical architecture design.
1-4
Lesson 1
Identifying Business Requirements
This lesson begins by explaining the importance of logical design when you are planning a SharePoint 2010 deployment. You can only design a successful SharePoint 2010 solution by gaining detailed knowledge of an organizations business requirements. The requirements must include both functional and nonfunctional business success criteria. By gathering this information, you can design a logical architecture for the business that is the foundation of more featurecentered design for individual components such as Search or business intelligence (BI).
Objectives
After completing this lesson, you will be able to: Describe the importance of planning a logical architecture. Describe the guidelines for gathering requirements. List approaches to requirements gathering.
1-5
Describe functional requirements. Describe nonfunctional requirements. Describe how to organize information.
1-6
Importance of Planning the Logical Architecture
Key Points
The core capabilities for SharePoint 2010 include: Sites. SharePoint 2010 can provide all business Web sites: corporate intranet, extranet, or Internet sites; project sites; personal sites; and so on. You can base all of these on a single architecture and even a single farm, which makes management and development easier. Communities or social computing. SharePoint 2010 delivers a range of social computing functionality and solutions, including personal sites, wikis, blogs, discussion forums, and tagging. All of these can be delivered in the corporate farm and corporate security standards. Content management. SharePoint 2010 provides document, records, Web content, and digital asset management that integrates seamlessly with Microsoft Office 2010, and previous versions of the Microsoft Office system. Search. SharePoint 2010 provides a range of enterprise search options for intranet search and people search, and a platform to build search-driven applications.
1-7
Insights or BI. SharePoint 2010 provides a range of BI tools including Excel Calculation Services, PerformancePoint Services, and Visio Services that deliver BI functionality to information workers in the form of dashboards, key performance indicators (KPIs), and Web Parts. Composites. SharePoint 2010 provides functionality for information workers to develop solutions, often accessing line-of-business (LOB) data to populate applications.
All of these are enterprise-ready capabilities, so it is essential that you undertake a rigorous design to ensure that your solution provides functionality that meets business requirements and is manageable for IT staff. Each capability in SharePoint 2010 is designed to meet the requirements of related workloads, such as enterprise content management (ECM) and Web content management (WCM), as SharePoint Server 2010 becomes more business critical in the enterprise.
1-8
Essentials of Requirements Gathering
Key Points
A common reason for the failure of an IT deployment is lack of effective planning and design. Technologists seldom fail to install and configure software and hardware platforms, but deployments often do not match the business goals of the organization. The first, and probably most important, component of a successful SharePoint 2010 deployment is a thorough knowledge of the target organization and its business goals. If a SharePoint architect fails to capture these requirements, it is highly unlikely that the eventual solution will succeed from the business viewpoint. As a solution designer, you must gather key business information to ensure that your solution reflects the requirements and goals of your organization. There are several essential dos and donts for gathering business information.
Assembling the Right Business Team

The first step is to gather a team that knows the business and has the authority to make decisions. This should include a business and IT sponsor, key stakeholders, and business users. You can extend the team to include technical experts, depending on your organizations platform infrastructure. If you do not have the
1-9
correct group in place, you will struggle to discover the real business requirements and to get effective validation of your analysis.
Preparing Your Questions

You should prepare your questions before you start the information-gathering process. By doing this, you can direct the discussion to ensure that you get the information that you require. A common mistake among new architects is to let users drive the information-gathering process, which can mean that the information is thorough in some areas, but does not give the designer the necessary information to map against a later technical design. This can lead to repeat interviews, which can be difficult to arrange. This may lead to a loss of confidence from senior business figures.
Focusing on the Business Requirements

Ensure that the design is business-led. A perfect IT implementation that does not meet business requirements is of little use to the business and will lead to loss of confidence in IT solutions. The development from technician to designer requires that you assess technology based on its ability to service business requirements, rather than reviewing its technical functionality or build quality.
Establishing a Licensing Budget

The logical architecture must reflect business requirements, but it should also reflect financial possibilities. You should establish the SKUs and options necessary to fulfill business requirements to ensure that these are realistic within your budget. This should also reflect the requirement for additional software or platforms, such as Office 2010 or Microsoft SQL Server 2008.
Including Functional and Nonfunctional Requirements

A good design may be one that causes least frustration. This means that you must design to ensure both functional and nonfunctional suitability. Users quickly become irritated by a solution that is slow or not available when they require it. You must gather both functional and nonfunctional information because the latter will have a major influence on your design.
Maintaining Documentation
When you have gathered information, make sure that you document the requirements and the logical solution. If requirements change, you must update the corresponding documentation accordingly. Without current documentation, it will prove impossible for your team to complete the design effectively. It is often just as important to avoid information-gathering hazards, so you should make every effort to avoid common requirements-gathering mistakes.
1-10
Avoiding Technology-Based Design

You should not focus your logical design on a given technology. Even if you are designing a SharePoint 2010 solution, you may find that there are business-critical components that require additional solutions or integration. Failure to identify these may lead to a solution that does not meet business requirements. You should identify requirements that may be out-of-scope for this particular project. SharePoint 2010 has a range of great technical capabilities, but you should ensure that your solution is based on business requirements, not solution features. The SharePoint 2010 features may deliver the functionality that solves a business requirement, but your design must always put the requirement before the feature.
Avoiding Leading Questions

When you prepare your questions, do not make them match your preferred solution, otherwise there is an increased chance that you will miss a requirement that does not fit with your predefined solution.
Updating Documentation
Design documentation is a set of living documents. As changes occur, you must return and update plans so that you have an ongoing business and technical description of the project. If you fail to do so, the documentation may become a description of the initial design, which you cannot use for sign-off or rebuilds.
Additional Reading
For more information about SharePoint 2010 licensing, see http://go.microsoft.com/fwlink/?LinkID=200849&clcid=0x409.
1-11
Approaches to Requirements Gathering
Key Points
When you need to find out about business requirements, you must ask managers and staff who work in the business. This may seem obvious, but sometimes computer analysts identify the technical solution and then force the business to fit.
Methods of Information Gathering

Common approaches to information gathering include: Sponsor and stakeholder interviews. You must engage with business sponsors and stakeholders. These people have the overarching vision for the business and the solution that they require. Business sponsors and stakeholders often have budgetary control of the project. Questions may include: What is the business vision for the organization? What is the budget for the project?
Focus groups. It is often more effective to gather teams together in focus groups to discuss business requirements. You should work with your sponsor and
1-12
senior stakeholders to identify the composition of the groups so that you do not get a skewed perception of the business. Questions may include: What key technology functions are required for your business division? What benefits do you want to realize from a SharePoint 2010 deployment?
User interviews. With the help of the business stakeholders, identify key users in the organization. These individuals will often have in-depth knowledge of business processes, and may have a big influence in decision-making. Questions may include: What are the key activities of your department and what functionality do you need to execute these functions? What are the major productivity issues facing your department that may be resolved through new technologies?
User questionnaires. These can provide an effective means of quantitative information gathering. A questionnaire should be well-structured, enabling you to gather key information for trend analysis. For example, social computing is an end-user solution. It is essential that you understand what the end users expect from any social computing solution. Questionnaires often consist of several closed questions and a few open-ended questions, which may include: Do you need to use social computing functionality for your work? What benefits will this offer?
Existing business processes. If there are existing business processes that your solution must supersede or complement, you must review these. From a technical viewpoint, you may need to integrate solutions, but you should first understand the function of any existing systems or processes and how users value them. You should not question existing business processes directly, but you should analyze them to identify elements such as: Can we re-create or extend this functionality in SharePoint 2010? What degree of customization is necessary to re-create this functionality and what will be the cost in resources?
Rules of Engagement
When you organize any business requirementsgathering sessions, you must create rules of engagement. It is particularly important that you establish time constraints. You should generally limit meetings to one hour, although this is
1-13
clearly a discretionary figure. Some meetings may require more time, particularly for larger teams or focus groups. The one-hour duration is based on the fact that most people are most attentive in the first 40 minutes of a meeting. If possible, you should get the core business completed during this time and use the final 20 minutes to confirm decisions. You can nominate a mediator to lead the sessions and a note-taker to take detailed notes. All meetings should have an agenda with clearly defined goals of what you want to achieve from the meeting. Without an agenda, meetings may lack focus, and some users may direct discussions to a personal agenda. When users raise topics that are outside the scope of the meeting, you must point out that such topics are extraneous and agree to address them in a separate meeting if necessary.
Types of Information
The options of qualitative versus quantitative analysis can be important, and both approaches are useful in gathering business requirements. Qualitative analysis takes information from a smaller but better informed group, whereas quantitative analysis draws information from a larger group. The key stakeholders and business managers represent qualitative information because they should have the greater overview of business goals. However, quantitative analysis, which is often in the form of questionnaires or larger focus groups, can highlight business processes that are unknown or unimportant to the business management team. Review existing business processes to ensure that you understand how the business works.
Reviewing Documentation
Always capture minutes of the meetings and allot time for attendees to review, validate, and sign off your analysis. Make sure that your documentation reflects business language, rather than transposing business requirements into computer jargon. Question: Describe any difficulties you have encountered in gathering user requirement information.
1-14
Functional Planning
Key Points
Functional planning identifies the functions or business actions that you must build into your design. You should define various levels of functionality in your information gathering. These vary depending on the audience that you interview. More senior business leaders tend to highlight overarching functionality, such as usability and increased productivity, which may appear conceptual and vaguely defined. However, your design will be measured by these factors, so you must ensure that you establish metrics by which these may be measured. For example, you can measure productivity by the speed with which a user can perform a task. If there is an existing productivity baseline, you must exceed it. It is useful to find the existing baseline because proving an increase in productivity without this may prove very difficult. Information workers are often more precise in their functional requirements. You must document these functional requirements thoroughly because they may ultimately provide the best proof of overall productivity improvements. You must remember that there is a difference between function and features. The former represents a business requirement, whereas the latter describes an
1-15
application or platform capability. Features must meet functional requirements, but individual features may be unnecessary for a business solution. There is a range of common functional requirements, but the most important is the need to perform business processes: You must map common functionality directly to business processes. The solution must be able to perform a task or achieve a goal. As part of your information gathering, you must list the key business processes that your SharePoint 2010 solution must complete. Ensure that you understand not only the task, but also the scope of the task. For example, there may be a requirement to tag documents consistently across an entire organization. Alternatively, tags may need to be unique in divisions. You may have to deploy a corporate information architecture taxonomy that is augmented by divisionally specific taxonomies. The administration of departmental or project Web sites may be a core requirement. This can affect options such as site permissions or self-service site creation, for example. Authentication and authorization are always important in design. You must ensure that security is robust, as corporate governance specifies, but complex layers of security must not impede the individual functions and tasks. Many organizations require IT solutions to conform to regulatory or statutory audit rules. This may extend beyond the bounds of user applications to include the application platform itself. Make sure that you understand the levels of audit and reporting requirements for regulatory compliance, so that you can apply appropriate policies in SharePoint 2010 for ongoing data management. Most corporate environments have complex integration requirements, which involve data being generated or collated in one system and visualized or analyzed in others. Your design must identify the potential interaction between systems, including authentication options. You should also identify any reporting requirements for divisions in your organization. This may be an important element of BI, which may not be a term that anyone in the business uses. You must be aware of the SharePoint 2010 functionality and how it maps to the business language that you gather.
There are elements of functional and nonfunctional planning that can merge, such as authentication versus security. It is important not to be overly concerned about whether a requirement falls into either category; if the business requires a capability, you should document it and include it to influence your design.
1-16
Question: List some functional requirements that you can identify in your organization.
1-17
Planning for Nonfunctional Requirements
Key Points
It is more common for business users to emphasize functional rather than nonfunctional elements, but failure to include the latter can have a catastrophic effect on your final solution. Although users and stakeholders assume that a system will always be available, you must plan for maximizing availability or performance. In your logical design, elements such as scalability, performance, and security may have a major impact on whether you deploy a single farm or multiple farms for an organization. The most common nonfunctional requirements focus on system capability, availability, performance, and so on. These may have a greater impact on physical design, but you usually only have one period of requirements gathering, so you must make sure that you get all of the information that you require. Key areas of nonfunctional planning include: Performance. Ensure that your design identifies performance issues such as the number of users who access the environment at peak times.
1-18
Capacity. Your design must provide sufficient capacity over an effective hardware management period, which is normally two years. This means that you have to specify systems that provide adequate storage for this period. In addition to the base systems, you must analyze the goals of the business to enable capacity for forecast growth. You must also be conversant with requirements that are specific to SharePoint, such as software boundaries, to ensure that data volumes do not exceed your logical architecture. For capacity planning for SQL Server, you may want to enlist expertise from a database administrator. Scalability. Your design must ensure potential for growth through scalability. This may involve scaling up, by upgrading the initial systems, or scaling out, with the addition of systems to share workloads. Your logical design should also provide options for extensibility through scaling. It is rare for an environment as rich and varied as the environment that SharePoint 2010 offers to remain static. You will often find that you must add or extend functionality such as social computing, BI, or Search in an organization. Availability. Users assume that systems will always be available for them to use, so you have to build this resilience into your plan. No system can guarantee 100 percent availability, so any service-level agreement (SLA) should establish the percentage of downtime that is acceptable for business continuity. This relates closely to availability solutions such as database clustering and network load balancing. However, your logical design must ensure adequate availability through the division of logical components across Web applications. Security. Security is an overarching goal, so your design may have to integrate with organization-wide standards. Secure authentication may also affect your logical design. You must ensure that you accommodate secure authentication requirements by identifying the division of site collections and sites. Manageability. If your deployment requires self-service provisioning, you must ensure that both administrative staff and delegated users can manage your solution. Interoperability. SharePoint 2010 provides a user environment that can visualize external data sources, for example, through out-of-the-box Web Parts. Your design must accommodate these requirements. Business continuity. As an extension to availability, you must address business continuity, or disaster recovery, options. This is often an organization-wide strategy, but you should review the SharePoint 2010 requirements.
1-19
There is no default priority for these nonfunctional requirements. You must prioritize each one based on the business requirements of your organization. When you have established the requirements for each one, review your results with the key stakeholders to establish the priority.
1-20
Organizing Your Information
Key Points
Irrespective of how carefully you recorded the interview information, you must organize it after the information-gathering process has finished. You must categorize information by functional and nonfunctional elements across the organization, identifying divisions, departments, users, and external users, and accommodating their various requirements. By doing so, you can identify how you can map the logical structure of the organization. Categorization also enables the designer to rationalize requirements, simplifying a design and minimizing repetition or duplication of effort. As in most patterns analysis, relatively few patterns are replicated across most organizations. You must identify the commonalities, assess any individual requirements (which you can treat as exceptions), and develop your plan based on this more manageable body of information. The key stakeholders and the business sponsor must sign off the final version of the requirements information. This documentation is the business specification of the project and amendments should trigger your change control process. In addition, senior IT stakeholders should sign off the nonfunctional components to
1-21
ensure that the elements of your requirements that do not relate to SharePoint 2010, such as security or network performance, are agreed.
1-22
Lesson 2
Overview of SharePoint 2010 Logical Architecture
The logical architecture of your business is the basis for your design. When you have gathered the business requirements, you must map these against the SharePoint 2010 logical architecture. This module provides an overview of the key logical architecture components in SharePoint 2010. Using this information, you can make key decisions about how SharePoint 2010 can service your business requirements.
Objectives
After completing this lesson, you will be able to: Define logical architecture. List the SharePoint 2010 logical architecture components. Describe hosting and multi-tenancy.
1-23
What Is a Logical Architecture?
Key Points
Most new solution architects focus on physical hardware design, rather than the logical architecture. This is often easier for new architects to understand because they are more familiar with specifying physical system properties such as disk capacity or memory. The logical architecture documents the nonphysical structure of a solution, designed to fulfill business requirements. The logical architecture does not specify any server-related functionality such as the amount or size of server hardware. Rather, it reflects requirements such as separation of departmental information or user access. These requirements do not relate to any given technologies or platforms. Although you may identify the need for databases, a logical architecture design does not specify a predefined database engine. One of the most important aspects of a logical architecture design is that stakeholders should recognize it as a true reflection of their business; otherwise they cannot agree to sign off your design. This means that you must provide
1-24
information in a nontechnical format that clearly documents business requirements. This course is about designing SharePoint 2010 solutions, but this should not influence your logical architecture design, which should be solution-agnostic. However, you should recognize the requirements that may relate to SharePoint 2010 and where other solutions may need to integrate to service business requirements.
1-25
SharePoint 2010 Logical Architecture Components
Key Points
The SharePoint 2010 logical architecture has several core components that will influence your design.
Server Farms
A server farm represents the top-level element of a design. Several criteria that your organization determines may affect the number of server farms that are required, including: Separate operational divisions of responsibility. Dedicated funding sources. Separate data center locations. Regulatory requirements for physical isolation between sites.
1-26
However, you can satisfy many isolation requirements on a single server farm. For example, you can use different Internet Information Services (IIS) application pools with different process identities to achieve isolation at the process level for both sites and service applications.
Service Applications
A service application provides a resource, or resources, that can be shared across sites in a farm or across multiple farms. In Microsoft Office SharePoint Server 2007, service resources were shared in the Shared Services Provider (SSP). This architecture has changed in SharePoint 2010 to provide greater flexibility and granularity of service. The service infrastructure is now implemented in Microsoft SharePoint Foundation 2010 and SharePoint 2010. You can design and deploy individual services independently, and you can add third-party services to your solution. This means that you can deploy only the servicesservice applicationsthat are required to a farm. Service applications are associated with Web applications and can have various configurations: Web applications can use only the services that are required, rather than deploying all services to all Web applications irrespective of whether they will be used. You can design multiple instances of the same service in a farm and assign unique names to each. You can share service applications across multiple Web applications in the same farm. You can share some service applications across farms.
Application Pools
In IIS 7.0, an application pool is a group of one or more URLs that a worker process or set of worker processes serves. When you create Web applications and services in SharePoint 2010 products, you can either select a pre-existing application pool to use or create a new one. Each application pool has its own worker process and can have a separate identity (security account), which prevents two processes from interacting.
Web Applications
A Web application is an IIS Web site that SharePoint 2010 creates and uses. You can extend a Web application up to four times to create additional zones in
1-27
SharePoint 2010, which results in up to five IIS Web sites that are associated with a single Web application. Each IIS Web site is associated with a different zone and you can assign a unique domain name to each.
Zones
Zones represent different logical paths (URLs) to gain access to the same Web application. In each Web application, you can create up to five zones by using one of the available zone names: Default, Intranet, Internet, Custom, or Extranet. This division into zones enables you to provide more than one URL for user access, which enables you to provide multiple authentication options. The Default zone is the zone that is first created when a Web application is created. You can create the other zones by extending a Web application.
Content Databases
By default, all content for a Web application is stored in one content database. You can separate content into multiple content databases at the site collection level. A content database can include one or more site collections. A single site collection cannot span multiple databases.
Site Collections
A site collection is perhaps the most important SharePoint logical design element. Site collections are a logical set of SharePoint sites that share the same top-level site and certain administrative settings. Each site collection contains exactly one toplevel Web site and zero or more subsites. Site collections are the highest level of logical containment within SharePoint; files and other items cannot be stored at any level higher than a site collection. In addition, site collections are autonomous and independent of each other; each site collection has its own security model, storage location, and configuration settings.
Sites
A site is a logical unit of containment that contains lists and libraries, permission levels, and configuration settings. Typically, a site is represented by one or more Web pages, which visually display Web Parts and other UI content. Each site can define its own security or can inherit from its parent. Sites are contained within a site collection.
Lists and Libraries

A list (or library) is a logical container that holds a collection of similar items such as contacts, appointments, and documents. Each list or library contains a number of columns of various data types (for example, text and date). Lists also contain configuration settings, permission levels, and views.
1-28
Items
An item is the most granular logical element in SharePoint, and represents a singular unit of content. For example, an item could be a document, a contact, or a custom row of data.
1-29
Hosting and Multi-Tenancy
Key Points
You can define hosting and multi-tenancy as follows: Hosting. The provision of distinct SharePoint 2010 services to a group, usually an external organization. Multi-tenancy. The architectural principle where a single instance of the software serves multiple client organizations (tenants).
Multi-tenancy is primarily designed for hosting companies, who supply SharePoint services to externaltenantcustomers. Administrators can deploy and manage features and services while giving tenants control over the usage and experience. Multi-tenancy relies on site subscriptions and subscription IDs. Tenant site collections are grouped together by site subscription based on a common ID. The subscription ID maps features and services and also partitions service data according to tenant. One or more of the following factors usually drive the inclusion of internal hosting in a business deployment:
1-30
Hardware and IT costs. Each environment, which is sometimes referred to as a property, requires unique configuration and thus hardware and management resources. Self-management. Users can manage their own environments, rather than have a central department provision all services. Financial resource management. Multi-tenancy, which is designed primarily for hosting companies, is easy to define for the purpose of internal cross-charging.
1-31
Lesson 3
Documenting Your SharePoint 2010 Environment
Documentation is a key element of design. Commonly, documentation follows the development of a solution, whereby developers document the technical aspects of a design. This lesson discusses documentation of your SharePoint 2010 deployment. Documentation is an essential tool for support and ongoing solution development, so you must understand what you should document in a SharePoint 2010 environment.
Objectives
After completing this lesson, you will be able to: Explain why you should document your SharePoint 2010 environment. Describe the areas of your SharePoint 2010 environment that you should document.
1-32
Why Document Your SharePoint 2010 Environment?
Key Points
Your documentation has several uses and you must direct it to a range of consumers. This means that you will have several layers of documentation that build on each other to describe overarching business requirements through to individual process documents. No single group consumes all of the documentation, but all of it will be used during the life of your deployment.
Stakeholders and Business Users

The information that you gather defines the business requirements for your design. It is essential that your business stakeholders, and possibly information workers, ratify this information. This means that you must make your documentation consumable by both of these groups, organizing their interviews or responses into a structured format. Stakeholders and other potentially nontechnical personnel must be able to view the documentation to map their goals in your solution. The documentation that you create acts as both a validation tool for sign-off by stakeholders, and a change control trigger. Of course, the documentation is also the blueprint for development, deployment, and maintenance.
1-33
Solution Architects
Solution architects use the logical architecture design to plan a solution. The logical architecture design underpins all of the work that comes later in the solution design. You must ensure that you have thorough documentation to enable them to map the physical architecture in later design processes.
System Administrators
System administrators use your documentationparticularly the physical design documentationto build and configure systems so that they meet functional and nonfunctional business requirements.
Developers
Beyond the base architectural design, developers will use these tables and diagrams to identify functional components of any customized design. For each custom component, there will be more detailed analysis and design, but the logical architecture design represents the environment in which any customization exists.
Living Documentation
One of the benefits of delivering published documentation from the outset of your project is the ability to manage change. It is nave to imagine that you, or the business users, can create an initial set of documentation that gets everything right. This means that your documentation is a living entity, which you must keep updated. It may seem that this point is labored, but the single biggest weakness of most documentation is that it is seldom current. You must establish documentation change management tasks so that you can be sure that your final documentation matches the business requirements. For major changes and additions, this should include validation by business stakeholders. It can sometimes prove difficult to get the time with sponsors to revalidate documentation. As part of your ongoing project management meetings, you should have a standing item to review change requests and sign off amendments and additions. Use this as the initial task of any project meeting, and it will become a recognized and valued part of the project. Current documentation is important because you can then update amendments and insert new functionality into your design. Note that it is difficult to amend accurately long or complex textual documentation in the form of reports. You are more likely to have inconsistencies in a 100-page document than you are in a table or diagram of one or two pages. It is also much easier to review concise documentation.
1-34
Your documentation, and particularly nonfunctional requirements, will become the blueprint for administration and support. Elements such as performance, capacity, and security requirements fashion the maintenance and monitoring schedules that you will establish for your deployment.
1-35
What to Document in Your SharePoint 2010 Environment
Key Points
Information-gathering processes for documentation run broadly in parallelyou will gather information that affects your logical architecture, physical architecture, security, and business applications simultaneously. There is seldom a chance to run a series of information-gathering sessions for each element of the design. The logical architecture design is the most important because it is the one that is more abstracted from the SharePoint 2010 technologies. If the logical design is incorrect, the implementation will not service the business requirements. Your documentation must include the following elements: Logical architecture design Service application architecture design Physical design Security and authentication design Metadata design Application design:
1-36
Search BI Content management
Operations and maintenance Business continuity
1-37
Lesson 4
Documenting the Logical Architecture
Now that you know why and what you should document, the next requirement is to identify an effective way to create documentation. It is common for documentation to be long and potentially unwieldy, but this makes information difficult to locate. You should focus your efforts on creating documentation that contains all of the relevant information, but remains easy to use. There are many documentation methodologies, some of which your organization may use or even prescribe. In this case, you should adhere to corporate governance. If you do not have such guidance, this lesson provides some effective documentation options for tabular and diagrammatic documentation.
Objectives
After completing this lesson, you will be able to: Describe the process of mapping business requirements to logical architecture. Describe the Logical Architecture Planning Worksheet.
1-38
Describe how to categorize business requirements. Transpose categorized business requirements to the Logical Architecture Planning Worksheet. Describe why you should use diagrammatic documentation.
1-39
Mapping Business Requirements to Logical Architecture Requirements
Key Points
Information from a range of sources and in a range of formats arrives for you, as a solution architect, to document and analyze. It is essential to reformat these to a consistent model that the business users can validate. The categorization of requirements should group logical components together so that individuals in the organization can recognize an end-to-end business flow, which they can then sign off. Business users often fail to see the importance of this stage because they may feel that you are telling them what they already know. However, it is essential for you to ensure that you have a complete picture of the business and the functionality required for a successful SharePoint 2010 deployment. Remember that, as part of this process, you can have a more objective view of the business and may be able to identify potential benefits that you can deploy across the organization.
1-40
Using a Planning Worksheet
Key Points
One way to document the logical architecture design is by using a planning worksheet. A planning worksheet provides a great deal of structured information in a usable and concise format. After you have identified the business requirements, you can map them onto the seven columns in the planning worksheet: Business requirement. This column should always be the first documentation element, because the logical design should always reflect business requirements. You do not need to have a cell for each business requirement. Rather, you must identify the requirements that will affect the number of Web applications that you need to deploy. Site name. This column identifies the working name for each site. The top level contains Web applications such as intranet, extranet, and Internet sites. Below these, you have site collections, which house multiple sites below the site collection. For example, you may have an intranet that provides sites for departments in your organization, such as IT or HR. These are site collections that will, in turn, host sites that are pertinent to these functional divisions.
1-41
Site URL. This column maps the URL and path for each site. The top level of the farm contains root URLs (/) such as www.litwareinc.com for the Internet site of Litware, Inc. Site collections in a Web application will have subsite URLs. For example, an intranet site may include a site collection (/sites), in which there are subsites, such as /sites/IT for the IT division or /sites/HR for the HR division. Parent site. This column identifies each of the Web applications in which all other sites exist. In the Litware, Inc. example, this may include Internet (www.litwareinc.com), intranet (intranet.litwareinc.com), or extranet (extranet.litwareinc.com) parent sites. Remember that My Sites should have its own Web application for performance and management reasons, such as my.litwareinc.com. Template. This column specifies the site template that is best suited to create the Web application, site collection, or site. The site templates provide core functionality that is appropriate to your site. Content database name. This column links the sites to content databases. These may be shared or used for specific secured or volume data. In your design, you should identify logical database divisions, such as Internet and intranet. However, you should also identify the software boundary limitations of databases so that you offer additional databases for large document storage environments. Remember that site collections cannot span content databases, so you must design for scalability. Notes. This column is for notes that explain the rationale or specific functionality associated with each site. Your design documentation is not like process documentation, where you list a series of steps that are the only way to complete a task. You should include justification notes to explain the logic behind your decisions, which will help you later when your design focuses on individual components of your deployment.
1-42
Sample Scenario: Identifying Business Requirements
Key Points
The slide displays a well-structured requirements document that contains a lot of information regarding your user requirements. As a designer, you must review this to identify the components that will influence and drive your SharePoint design. It is usually easy to locate volume information such as the number of users, sites, or data volumes. You should also be able to find less metric-based information. You can see from the highlighted elements of this slide that there is a lot of information that should affect your design. As an approach, highlighting elements that you think will influence logical architecture design is very useful. It maintains the integrity of the document, so that you do not unwittingly change the requirements, while identifying the key components. You may choose to use various highlighting colors or add comments to categorize these elements.
1-43
Sample Scenario: Mapping Business Requirements to Logical Architecture
Key Points
Mapping your business requirements to a planning worksheet helps you map the logical components of your design. There is a range of business requirements that you can identify from this short document and map to the Logical Architecture Planning Worksheet.
Worksheet Columns
1. The required departmental intranet sites. The Litware, Inc. site requires divisional sites (implemented as site collections) for each of the six departments. Each site collection is based on a publishing template because the intention is for the departments to publish internal information. The required Internet-facing site and its products subsite. Litware, Inc. requires an Internet site that can show all product information, so you should use a dedicated Web application. This will almost certainly require anonymous access for casual browsers. It is also likely that the Litware, Inc. Internet site
2.
1-44
will require other components to be published, such as About Us information, for example. 3. The extranet site and subsites for partners. There is a business requirement for extranet access to partners, in addition to sites for each partner. In this case, there is a site collection called /partners below which each individual partner site can be hosted. The My Sites requirement. The requirements specifically state that there is a desire to start using social computing to aid communications in the organization through the availability of personal Web sites. This means that you will need a My Sites Web application. For security, capacity, and performance reasons, it is good practice to dedicate a Web application to My Sites. This will also influence the physical design because you should keep your Active Directory directory service server local to maximize performance. There is no specification that Litware, Inc. is a multinational organization, but you should check. In the notes, you can see that there is no specification for self-service site provision. As a designer, you should check this because it would have a major impact on IT administration. Each My Site is a site collection, so you can estimate the number of My Sites. This will influence the volume of content and therefore any quotas that you may set on personal sites.
4.
1-45
Using a Visio Diagram
Key Points
The use of Microsoft Visio diagrams can provide a visual representation that will augment information in a spreadsheet or report table. This form of documentation is popular because it provides a summarized structure that is easy to consume. The graphical elements make it easier to identify each logical component in the SharePoint logical architecture. Diagrams should be kept simple and provide a high-level summary of the design. By using both tabular and diagrammatic documentation, you can deliver a documented design that is both easy for business and IT users to visualize, and contains all of the information that you require to influence detailed design for physical or other planning.
1-46
Lab: Designing a Logical Architecture
Exercise 1: Mapping Business Requirements to a Logical Architecture Design

Scenario
Central IT at Contoso, Ltd has completed the business requirements gathering and the stakeholders have approved its findings. Central IT has tasked your team with creating a logical architecture design that addresses these requirements. The information that your team has gathered is detailed in the supplied documents. Use these documents to produce your logical design. The main tasks for this exercise are as follows: 1. 2. Read the supporting information. Complete the Logical Architecture Planning worksheet.
1-47
Task 1: Read the supporting information

1. 2. 3. 4. Log on to 10231A-NYC-DC1-01 as CONTOSO\Ed with the password Pa$$w0rd. Read the lab scenario. In the E:\Labfiles\Lab01\Starter folder, read the information in the Contoso Business Requirements.docx file. In the E:\Labfiles\Lab01\Starter folder, read the information in the Logical Architecture Requirements.docx file.
Task 2: Complete the Logical Architecture Planning worksheet

In the E:\Labfiles\Lab01\Starter folder, complete the worksheet in the Logical Architecture Planning Worksheet.xlsx file.
Exercise 2: Creating a Logical Architecture Diagram

Scenario
You need to create a graphical summary of the content in the completed logical architecture worksheet. The main task for this exercise is to complete a logical architecture diagram.
Task 1: Complete a logical architecture diagram

In the E:\Labfiles\Lab01\Starter folder, complete the diagram in the Logical Architecture Diagram.vsd file.
1-48
Module Review and Takeaways
Review Questions
1. 2. 3. What are the key differences between functional and nonfunctional requirements? Outline the essential things that you should do when gathering user information. Which are the key components of your logical design that you should document in a Logical Architecture Planning Worksheet?
Best Practices Related to Creating a Logical Architecture Design

Supplement or modify the following best practices for your own work situations: When you are designing a SharePoint 2010 solution, it is essential to map business requirements to a logical architecture design before you start to deploy.
1-49
Always validate your design with your stakeholders. This ensures that you fully reflect their business goals and they understand your design functionality. Always update changes to your documentation.
Planning a Service Application Architecture
2-1
Module 2
Contents:
Lesson 1: Introduction to the Service Application Architecture in SharePoint 2010 Lesson 2: Service Application Architecture and Components Lesson 3: Topologies for Service Applications Lesson 4: Mapping Service Applications to Your Logical Architecture Lab: Planning a Service Application Architecture 2-4 2-18 2-31 2-43 2-50
2-2
Module Overview
This module reviews the role of the service application architecture in Microsoft SharePoint 2010 and examines its effect on your solution design. The way in which you deploy services has changed fundamentally since Microsoft Office SharePoint Server 2007. SharePoint 2010 has a granular approach to service provision, so you can add service applications for any Web application on an individual basis. Office SharePoint Server 2007 had a centralized approach to service deployment, and you implemented all services through a single Shared Services Provider (SSP). Your SharePoint 2010 service application design can be more flexible than was possible previously, so it is important to understand how to implement services and plan your topology for SharePoint 2010. Objectives After completing this module, you will be able to: Describe the service application architecture in SharePoint 2010 and list the available service applications.
2-3
Describe the components and options that are available in the service application architecture in SharePoint 2010. Describe some of the topology options for service applications and their respective benefits. Describe how to map and document business requirements to service applications.
2-4
Lesson 1
Introduction to the Service Application Architecture in SharePoint 2010
The new service application architecture in SharePoint 2010 is a paradigm shift from the SSP model in Office SharePoint Server 2007. It is essential that you understand the available service applications so that you can develop the best SharePoint 2010 solution for your organization. The new, more granular, architecture offers opportunities for solution architects. However, this flexibility comes with a responsibility to become fully conversant with the subtleties of the service interrelationships.
Objectives
After completing this lesson, you will be able to: Describe the service application architecture in SharePoint 2010. Describe the differences between the SSP model in Office SharePoint Server 2007 and the service application architecture in SharePoint 2010.
2-5
List the available service applications. Describe the security model for service applications. List dependencies between service applications. Describe the benefits of service applications.
2-6
Service Application Architecture in SharePoint 2010
Key Points
Service applications provide specific functionality to users in SharePoint 2010. This includes access to application functionality with Microsoft Excel 2010, Microsoft Visio 2010, or underlying services such as the Managed Metadata Service or the Business Connectivity Services. The framework of the service application architecture in SharePoint 2010 is designed to enable architects to select only the services that are required to deliver a business solution. This is a major shift from the SSP in Office SharePoint Server 2007. A service application has the following components: An administrative interface, through which you can manage the associated service application An application pool A service database or databases, dependent on the requirements of the service A service application proxy group
2-7
One or more physical instancesthe service process running on a physical server
The service application architecture runs across the SKUs from SharePoint Foundation 2010 through to SharePoint 2010 Enterprise, though not all SKUs offer all of the SharePoint services. The service application architecture is also extensible, so third-party vendors can develop service applications that you can deploy in your solution. The flexibility of the service application architecturewhere you can deploy multiple instances of the same serviceprovides a range of design options for SharePoint 2010 architects. You can implement multiple instances of a service application for resilience, performance, or security. The service application architecture has its own set of terminology; it is important to understand these terms as you work with your team to develop a design. The following list explains the terminology: Service. The binary files that are installed on the server farm to execute a function. Service application. The implementation of the service on a farm, including any farm-specific configuration. Service application proxy. The target for user calls to the service applications. User calls are not direct, but use Windows Communication Foundation (WCF) to communicate with the service via a proxy. The service applications that are consumed through a Web application are termed a proxy group. The proxy is a point to this service that handles calls through a Web Front End (WFE) server. Service instance. A single implementation of a service application. You can implement multiple instances of a service application in a variety of configurations, either in the same proxy group or in multiple groups. These instances run on an application server. You can deploy multiple instances to provide isolated services or to improve performance through load balancing. Service consumer. This term describes the features that use, or consume, the functionality that the service application provides. This may be an Excel Web Part that renders Excel Services information in a browser.
Question: Why would you use multiple service instances?
2-8
Comparison of Service Applications in Office SharePoint Server 2007 and SharePoint 2010
Key Points
The move to the service application architecture is probably the most significant architectural change in SharePoint 2010. For architects who are moving from Office SharePoint Server 2007 to SharePoint 2010, it is important to understand the differences between these approaches to service deployment. Office SharePoint Server 2007 provided the SSP to deploy a number of productivity services, such as the Business Data Catalog (BDC) and Excel Calculation Services. You typically only used one global SSP, which supplied all services to all Web applications. This had several consequences for the solution architect: The monolithic design meant that all services were available to all Web applications; you could not have a separate service for one Web application. For example, if your Accounts department wanted access to Excel Calculation Services and the Marketing department wanted access to BDC, you had to provide everyone with access to both in the farm. This was clearly a waste of resources, and it also limited the security functionality of SSP.
2-9
There was only one SSP for each farm, which meant that there was a single point of failure. If this SSP failed, all users lost all SSP functionality. SSP was inflexible in deployment. You could not implement granular services to individual business groups, so a design inevitably provisioned services to users who did not need them. SSP was not extensible. Only services that Office SharePoint Server 2007 provided were available.
The new architecture in SharePoint 2010 offers far greater design scope for architects. You can now deliver the right set of functionality to the right users without deploying unnecessary services to all users. This enables architects to: Deploy granular services, delivering only the services that are requested for each Web application. Design a flexible deployment that provides scalable resilience and security through the implementation of multiple instances of service applications. This enables you to deploy multiple instances of a service application, such as Excel Services, which are isolated from each other, so that independent departments or groups do not share Excel content. Manage performance by deploying multiple instances of a service application for the same Web application. Each service application demands resources such as memory and processor. For example, PerformancePoint Services can be processor-intensive, so you can deploy multiple service instances to maximize performance. Extend service functionality by deploying third-party service applications or by purchasing additional service application SKUs such as Microsoft Project Server 2010.
2-10
Service Applications in SharePoint 2010
Key Points
SharePoint 2010 SKUs provide a range of services that architects can use to deliver business requirements. The range of service applications grows with each level of SKU functionality, from SharePoint Foundation 2010 through SharePoint 2010 Standard to SharePoint 2010 Enterprise. It is important that you identify the right SKU for your organization, because this will save time and money. In addition to these service application options, there are some service applications that are delivered by default: The Application Discovery and Load Balancer Service Application.This service provides administrative functionality for the service application architecture, such as registering servers on the farm and grouping service applications across Web applications. The load balancing functionality means that you can provide the best available performance by providing multiple service application instances to which SharePoint 2010 can route user requests. This happens automatically. You may also see this called the Topology Service Application, derived from the Windows PowerShell command SPTopologyServiceApplication.
2-11
The Security Token Service Application. This service manages authentication by acting as a broker for SharePoint 2010. It can support multiple authentication providers.
Most of these services are self-descriptive, such as Excel Services and Access Services. However, there are some services that are important for your design but have less obvious roles. The following list describes these service applications: Secure Store Service. This service provides single sign-on (SSO) proxy functionality. This is essential if you want to use the Business Data Connectivity Services to access line-of-business (LOB) servers seamlessly for users. Managed Metadata Service. This service provides the capability to create and store the taxonomy information, such as document metadata, that is used throughout SharePoint 2010. This is a core function for many other services. User Profile Service. This service provides social networking functionality, such as user profile import and People Search. Business Data Connectivity Services. This service provides read and write access to LOB data sources. This is essential for deployments that must deliver composite application functionality to users. State Service. This service provides temporary storage of user session data for SharePoint Server components.
2-12
Service Application Security Model
Key Points
SharePoint 2010 has updated its security model to offer claims-based authentication. There have also been changes that affect the service applications. Core to this is the fact that service applications use WCF to communicate between services. Although this does not change the user experience, it provides improved performance and security flexibility. It also supports Secure Sockets Layer (SSL) transports. The service application architecture enables you to isolate services from one another. You can achieve this at service instance, application pool, and database levels, depending on whether your service uses databases. If your business requires more rigorous security for applications, you can design your solution so that the service applications are separated, to ensure that users of a service application do not share any components with other users. Hosting companies or organizations that want to use multi-tenancy to separate divisions or departments can still share most service applications. This is because these applications are designed to be capable of multi-tenancy. You can also isolate service applications in a multi-tenancy environment.
2-13
These service applications can store tenant data and can be partitioned: Subscription Settings (not actually partitioned) User Profiles Managed Metadata Business Data Connectivity Search Secure Store Word Automation Project
These service applications do not store tenant data, and do not support Partition Mode: State Access Database Visio Graphics Word Viewing PowerPoint Excel Calculation
These service applications can store tenant data, but cannot be partitioned: Web Analytics (site-based) Usage and Health Data Collection (site-based)
These service applications cannot be partitioned, and consequently do not make sense in multi-tenant environments: PerformancePoint FAST for SharePoint
2-14
Service Application Dependencies
Key Points
Not all services are entirely self-contained, so you must review possible service dependencies when you plan your logical architecture design. This was not an issue with Office SharePoint Server 2007, because the services were implemented in a monolithic design. However, with the granular framework in SharePoint 2010, it is now possible to deploy dependent service applications without enabling core service applications. Dependent service applications will not function as expected and may not function at allwithout the required platform services in place. Some dependencies are more obvious than others, such as that between functions such as People Search and the User Profile Service. If you do not have the ability to import user information from external sources, such as HR systems, you will not be able to make the best use of People Search. Others are less obvious. For example, Excel Services is dependent on the State Service to provide temporary storage. The slide shows some common dependencies that will affect your service application planning. You may find papers on the Web that categorize service applications as core or foundation services and the framework as hierarchical. This
2-15
is not a description that is used directly in SharePoint 2010 documentation, but it does describe the functional design. The list on the slide is not an exhaustive list of dependencies. Question: Which two services are prerequisites for the Business Connectivity Services?
2-16
Benefits of Service Applications
Key Points
As you have already seen, the new service application architecture in SharePoint 2010 provides a number of benefits. When you start to plan to provide for business functionality, you must ensure that you take advantage of the options for deploying service applications. Listed below are some overarching benefits that you should remember: Granular deployment. You should identify the Web applications where users require service application functionality and design that is based on a principle of minimal deployment. Flexible configuration. You can provide scalability in your design by ensuring that you provide the right configuration of instances to maximize performance and resilience. Round robin load balancing is an integral feature of SharePoint 2010 service applications, and it is a major benefit when you design for multiple instances.
2-17
Delegated administration. You can minimize central IT overheads and provide more effective local management by delegating administration of service applications. This capability means that local administrative users can provide first line support, but it is essential that you plan training as part of your design. Shared services across Web applications. You can share service applications across Web applications. This enables you to create requirement-specific service application instances to provide greater performance, perhaps by scaling up servers that host these services. Rather than deploying across all Web applications, SharePoint 2010 enables you to develop designs that share service applications only between Web applications where users need specific services. For example, you may share a Managed Metadata Service between Web applications that share common taxonomies. You can extend this to provide multiple Managed Metadata Service instances to deploy a common taxonomy for the entire organization, with Web applicationspecific taxonomies. This is functionality that is unique to the Managed Metadata Service. Shared services across farms. You can also design your solution to share service applications across farms. This is called publishing a service application. You can design a solution that installs one farms application proxy on another farm and point it to a universal resource indicator (URI) location.
2-18
Lesson 2
Service Application Architecture and Components
For a solution architect, it is important to understand the options for service application design. It is also important to understand how the structure of the farm topologies in an organization can benefit from the various topology options for service applications. Many service applications integrate with external data, so a solution architect must also understand how the SSO options that the Secure Store Service offers can benefit a design.
Objectives
After completing this lesson, you will be able to: Describe the workflow of a service application. List the components of service applications. Describe the logical architecture of service applications.
2-19
Describe the options for cross-farm service application sharing. Explain the requirements for service applications that need to consume external data.
2-20
Service Application Workflow
Key Points
Service applications deliver service functionality to users. When a user triggers a service request from a browser, the requestsuch as a keyword searchis sent through the WFE server, which may be preceded by a hardware network load balancer. The WFE server sends a request through to the application server that serves the service application. The service application architecture in SharePoint 2010 enables multiple servers to deliver instances of the same service application, so there is a software load balancer that routes requests to the appropriate server. All communication uses WCF, so there is no direct access to the service application databases. By default, communication between Web servers and service applications in a farm takes place by using HTTP (port 32843), but you can select either HTTP (port 32843) or HTTPS (port 32844). Third-party companies that develop service applications can also implement NetTcpBinding (port 32845) to provide high-performance communications with WCF clients. NetTcpBinding is generally the best option for services operating inside a firewall, such as on an
2-21
intranet site. Administrators can use the Service Applications page to change the protocol and port binding for each service application. Communication between service applications and Microsoft SQL Server takes place over the standard SQL Server ports or the ports that you configure for SQL Server communication. For the following service applications, information is cached to improve performance: Access Services Excel Services PerformancePoint Services Word Automation Services
The Visio Graphics Service uses a binary large object (BLOB) cache, which provides higher performance when it renders large drawings. Question: What is the default port number for service application communication over HTTPS?
2-22
Service Application Components
Key Points
A service application is made up of a number of components that work together to deliver service functionality to the end user.
Service Application Connection (Proxy)

When you deploy a service application, you create a service application connection. This connection is more commonly known as a proxy. The proxy manages the connection information so that the service application can communicate with service requests from service consumers, such as Web Parts. You can link and manage service applications against individual Web applications. This means that you have the flexibility to deploy multiple service application instances, which you can isolate to match performance or security requirements. You should remember that by default, service applications are associated with all of the Web applications on a farm, so you have to specifically associate service applications to Web applications. You can manage proxies through the SharePoint Central Administration site or by using Windows PowerShell.
2-23
Service Application Proxy Groups

SharePoint 2010 groups service applications together for Web application consumption through proxy groups. These are simply groupings of service applications that you can deploy to different Web applications. This may seem trivial, but this is an important design mechanism for solution architects for grouping and isolating service applications. By default, all service applications are placed in the Default group. This means that all users in Web applications that consume services from the Default group have access to the group members. However, you can create custom groups, to which you can add services that you want to provide to a specific Web application. When you create a Web application and choose a custom group, only that Web application can consume the services. If you create a new service application through the Administration UI, it is added to the Default group. However, you can move service applications to other groups or change their association with Web applications. When you use Windows PowerShell to create a new service application by using the new-spserviceapplicationproxygroup cmdlet, the service does not automatically join the Default groupyou must add the default switch. A Web application does not have to consume all of the services in a proxy group; you can configure this through the Configure Service Application Associations page on the SharePoint Central Administration site.
Databases
One of the biggest surprises for designers and database administrators (DBAs) who are familiar with Office SharePoint Server 2007 is the large number of databases that are associated with service applications. If you upgrade an Office SharePoint Server 2007 farm to SharePoint 2010, these are automatically generated for each upgraded or new service. The system-generated names for these databases are not easy to relate to the service application. For easier management and recognition, you should define your own database names for your service application databases. In addition to naming, you should be aware of the potential size to which these databases can grow. For example, the Usage and Health Data Collection database can become very large if you use the out-of-the-box configuration. It will log approximately 2 gigabytes (GB) of data for 1 million HTTP requests. This database may grow to an enormous size if you do not reconfigure it to limit either the range of captured information or the length of time that you store this information. As a result of this potential for growth and the associated write activity, you should also consider putting this database on a separate disk.
2-24
Some service applications have multiple associated databases, such as the User Profile Service and the Search Service.
2-25
Logical Architecture of Service Applications
Key Points
The logical architecture of service applications is an important element of design. There are some service applicationspecific configuration or deployment options, but it is useful to understand how you can deploy services. The slide shows a series of nonspecific service applications in a sample SharePoint 2010 farm. This is a simple configuration with: One farm. One service application application pool. Two Web application application pools. Three Web applications.
The service applications are all deployed in a single Internet Information Services (IIS) Web site, which is the default requirement for SharePoint 2010. The design of this solution has two proxy groups: the Default proxy group and the custom proxy group. Although the default action is to have service applications in
2-26
the Default proxy group, it is not mandatory. Some of the service applications are in a custom group, and one is not in the Default proxy group at all. Service applications can also be in more than one proxy group. This means that you can share services among Web applications without having to share all of them. In this case, service application X is isolated so that only users who are associated with Web application A can use it. It is possible to create separate application pools to separate the service applications at the process level. Notice that there are multiple instances of service application Y in the Default proxy group. This provides greater performance, because these instances are on separate physical servers and can therefore provide load balancing. This configuration will also ensure greater resilience, because the service application will still be available even if there is a single server failure. You may isolate service applications for security purposes and this isolation is done at the process level only. If performance is the reason for isolating this service application, you can include additional instances.
2-27
Cross-Farm Service Applications
Key Points
Although you can share all service applications across Web applications, there are only six that you can share across farms: User Profiles Service Managed Metadata Service Business Connectivity Services Search Service Secure Store Service Web Analytics Service
The first four are most commonly shared across farms. In your design, you should assess the options for sharing one or more of these if you decide to deploy multiple farms.
2-28
Factors that may encourage you to share service applications between farms may include: A requirement to minimize management overhead for popular services, such as search. A decision to create a service farm to centralize resource management. A requirement to share an organization-wide resourcesuch as a taxonomy through the Managed Metadata Service.
The cross-farm sharing process has a number of elements that you must plan and execute prior to deployment: Configure trusted farms. Farms must exchange security certificates. Publish the service applications. On the sharing farm, you must publish the service application so that external farms can consume it. You use the Application Management page to do this. Connect to cross-farm service applications. On the consuming farm, you must create a connection to the published service. This uses the URI that is generated in the publishing process. Set appropriate permissions. The consuming farm must have permission to the Application Discovery and Load Balancing Service Application on the publishing farm. It must also have permissions to the service that it will consume.
An additional level of planning is necessary for farms that are located in different domains. You must ensure that the following conditions are in place to share these service applications: User Profile Service. To share the User Profile Service, you must configure twoway trust between domains. Business Data Connectivity Services. The publishing farm domain must trust the consuming farm domain for an administrative feature to function. Secure Store Service. The publishing farm domain must trust the consuming farm domain for an administrative feature to function.
2-29
External Data Source Access
Key Points
It is common to implement delegated Windows identities when a service application must use an impersonated identity to access remote resources. The service applications that use delegated Windows identity are: Excel Services InfoPath Forms Services PerformancePoint Services Visio Services
If the service application and the target external data are not in the same domain, you can configure these service applications to use the Secure Store Service to provide managed user or service credentials. Without the Secure Store Service configured, it is not possible for these services to successfully authenticate to gain access to the external data.
2-30
This does not affect other services that access external data, such as the Business Connectivity Services.
2-31
Lesson 3
Topologies for Service Applications
The flexibility of the service application architecture means that there is no single correct solution for all SharePoint 2010 environments. You must review the business requirements, IT drivers, and governance directives to identify the best solution for your organization. You must understand the available options and their benefits and disadvantages before you plan your service application architecture. One of the advantages of the architecture in SharePoint 2010 is its flexibility, so you can modify your deployment if your business requirements change.
Objectives
After completing this lesson, you will be able to: Describe the impact of service applications on solution design. Describe the advantages and disadvantages of designing service applications in a single proxy group.
2-32
Describe the advantages and disadvantages of designing multiple service application proxy groups in multiple application pools. Describe the advantages and disadvantages of deploying multiple service application proxy groups in a single application pool. Describe the advantages and disadvantages of an enterprise service farm topology and cross-farm sharing of service applications.
2-33
Effect of Service Applications on Topology Design
Key Points
Service applications can have a major impact on the topology of your overall solution. This is because users want functions and service applications offer a wide range of functionality. The breadth of these service offerings means that you can chose from a wide range of implementation topologies. The flexibility of the service application architecture enables you to create many alternative designs. It is important that you ensure that your design is functional rather than unnecessarily complex. Key elements to remember when you select your topology design include: Granular topologies. Most important is that you use the granularity of the service application architecture to ensure that you can deliver the business requirements across the organization without wasting resources, such as administrative time or hardware budget. Extensible topologies. Remember that you can now extend your service architecture. This does not just mean that you can add service applications or extend across farms or domains. You can increase performance or capacity by
2-34
adding service instances to deal with growth. This may also be an option for managing spikes in demand or unexpected changes in usage. Service-driven topologies. There is also the option for developing a service applicationdriven topology. This may sound unlikely, but search is a service application and it is common for organizations to set up search-specific farms. You may choose to extend this beyond a specific service and include a range of services. The key point is the service application flexibility, which should encourage you to design a solution that will fit your business.
2-35
Topology for a Single Farm with a Single Service Application Proxy Group
Key Points
The slide shows a relatively simple topology. All of the service applications are in a single Default service application proxy group. All sites have access to all of the farm service applications. This may seem a very simple approach, but simplicity is often the most elegant solution. This option is easy to deploy and manage because much of the configuration capitalizes on the default settings. The design offers centralized maintenance with minimal effort, and it is unlikely that users will have issues when they access service applications. If there is an issue regarding this topology, it is scalability. There is no separation of services dependent on the requirements of unique areas of the business. There is also no option for individual departments to manage their own service applications. Therefore, if the volume of business increases, the load on the central IT team may also increase.
2-36
This is almost certainly the most common deployment topology for service applications, although part of that may be to do with the fact that it works for the majority of new installations. If this is the solution that you choose, you should review it as part of your ongoing review process to determine whether your organization may gain benefits from other deployment options for service applications.
2-37
Topology for a Single Farm with Multiple Service Application Proxy Groups in Multiple Application Pools
Key Points
The topology on the slide provides a greater element of isolation for users in Web App 1 because it implements a custom service application proxy group. This provides these users with a set of service application resources that are not available to the farm users of Web App 2 and Web App 3. This solution provides greater isolation by putting services that are dedicated to the custom group in a separate application pool. It is important to note that you can share service applications across both Default and custom groups. You can also share them among Web applications. In this topology, simplicity is sacrificed to greater granularity. This inevitably makes management more complex, but this should not be an issue if you maintain documentation of your solution.
2-38
There is greater isolation of services, which provides some data security. It may be that one of the service applications in the custom group is a second instance of a service application that is available in the Default group. Deployment of another instance will consume additional farm resources, but this may be justified by the increased granularity of service.
2-39
Topology for a Single Farm with Multiple Service Application Proxy Groups in a Single Application Pool
Key Points
The example on this slide looks considerably more complex, but it is just an extension of the practices that the previous examples used. In this example, the farm has more than one custom group. This may be a requirement because several divisions require a single service to be isolated. For example, each may use an instance of Excel Services that they want to keep separate, perhaps maintaining different databases to increase separation. You can also use this type of topology to provide unique service applications to individual Web applications, which use a delegated model to reduce pressure on central IT resources. Topologies that provide custom service application proxy groups are most useful for organizations that have divisions or teams that require a degree of separation from the rest of the business. The custom group may also be useful for specialist sites where separation is essential, such as sites that provide access to external partners or customers.
2-40
Topology for Enterprise Service Farms
Key Points
Enterprise organizations are not always more complex than other environments. However, they are usually much larger, so there is greater scope for more unique requirements and pressing solution boundaries. Remember that if you work for a large enterprise, it does not mean that you must design a complex solution. In the scenario on the slide, there are a number of different approaches to service application deployment.
Enterprise Services Farm

You can use an Enterprise Services Farm to share service applications. This enables the central IT department to provision all shareable services across the organization, such as corporate taxonomies through the Managed Metadata Service. This topology is also attractive for pan-organization Search Service implementations.
2-41
Farms with No Local Service Applications

Farm A has no local service applications, but consumes all of its services from the Enterprise Services Farm. This limits the range of possible services to the User Profile Service, the Managed Metadata Service, the Business Connectivity Services, the Search Service, the Secure Store Service, and the Web Analytics Service. This means that the farm is probably not one where users would consume more obvious functional service applications, such as Excel Services or Visio Services. This design is probably best suited to publishing environments. The benefits of this design include: Centralization of resources on the Enterprise Services Farm. Reduced administrative overheads on Farm A. Provision of pan-organization services, such as the User Profile Service and the Managed Metadata Service.
Collaborative Farms
Farm B has a range of local services, which makes it more useful for collaborative working because these may include Excel Services and Access Services. This taxonomy still benefits from the organization-wide User Profile Service and Managed Metadata Service. Note that there is a divisional Managed Metadata Service on Farm C, which indicates that there is a subgroup taxonomy that is applicable to both Farm B and Farm C. The benefits of this design include: Access to centralized service application resources. Local administrative capability. Integration with other farms.
Specialized Farms
Farm C is a smaller environment, with only one Web application that uses primarily local services. This may indicate that this is a specialist department that has specific requirements. In this instance, the Excel Services and Business Connectivity Services applications are isolated from other farms. This farm also has its own Managed Metadata Service so that it can manage a taxonomy that is distinct from the organizations taxonomy.
2-42
The benefits of this design include: Service isolation. Metadata autonomy. Access to centralized services, such as the User Profile Service and the Managed Metadata Service.
2-43
Lesson 4
Mapping Service Applications to Your Logical Architecture
All design must be driven by business need and documented by the solution architect. For service applications, you must design your solution based on the existing logical architecture. This is an additional layer of functionality that will lead to a final overarching set of design documentation. When you map requirements to service applications, you must ensure that you get business stakeholders to sign off the design. This will largely be a high-level agreement on function because supporting services will have little meaning for most business users. As with the logical design, it is essential that you maintain the documentation of your service application for management and administration purposes.
2-44
Objectives
After completing this lesson, you will be able to: Describe how to identify the service application requirements for an organization. Describe how to use a planning worksheet to document service application instances.
2-45
Identifying Business Requirements for Service Applications
Key Points
Mapping business requirements to the available service applications demands that you have a thorough understanding of what service applications offer and what your business users want to achieve. It should not be your goal to use as many service applications as possible, but to use the right ones. For example, just because information workers use the Microsoft Office system does not mean that you should deploy all of the service applications that are related to Microsoft Office; these are necessary only if you want to use their functionality.
Required Applications
Identifying service applications that the organization requires is dependent on the information that you gather as part of your analysis of business requirements. It is rare for a user requirements document to specify any need for the User Profile Service, so you must interpret which services are necessary to deliver business functionality. For example, if the business requirements specify that the business wants to use more social computing functions, such as tagging and My Sites sites, you should be able to rationalize that to a need for the User Profile Service.
2-46
Isolated Services
When you have identified all of the required services, you should then identify whether some divisions or departments have a requirement for isolated instances of these services. This is not a function of preference, but rather a result of real business need. For example, a department may have a taxonomy that they want to use for search. If this is unique to this department, you should consider deploying a separate service instance that enables departmental users to manage their own taxonomy. These users will not be separated from the corporate Managed Metadata Service, but they will have an additional taxonomy that they can use. You may also need to identify the level of isolation that is necessary for service applications so that you can decide whether to provide separate service application databases.
Multiple Instances
You should identify which, if any, services are critical to your business and a level of performance that is acceptable to the users. When you have this information, you may choose to include multiple instances of important service applications for improved performance or increased security. If you do require multiple instances for resilience, ensure that you host these instances on separate servers. For example, you should implement two instances of Excel Services in the same application pool to ensure increased availability for users of Excel Services. By having two instances on separate servers, you can ensure that the service continues, even if an application server fails.
Performance
All service applications place resource demands on servers. If you have a series of resource-intensive service applications, such as Excel Services or the Visio Graphics Service, you should ensure that you implement these on separate platforms.
Multiple Farms
From a performance and management perspective, your goal should be to deliver a single farm solution for your organization. Often architects regard farm separation as the first, or even only, option to isolate users. However, Web applications and site collections are the first options that an architect should select. Remember that you can only share six services across farms. If you must deploy multiple farms, you should identify and group common requirements so that you can design for easy management and better performance.
2-47
Centralized Services
If you have a compelling reason for establishing two or more farms for your deployment, you should identify which of the available service applications you can share. This will minimize administrative overheads and create a corporate unity for business components such as social computing.
2-48
Mapping Instances by Using the Service Applications Planning Worksheet
Key Points
You must document the service applications that you plan to implement and the core information about these. You should always maintain documentation about the service applications that you deploy. This will help you to maintain the environment. It will also enable you to ensure that you have configured dependent service applications.
Planning Worksheet
The planning worksheet is specific to the logical design that you have created for your organization because it reflects the Web applications with which services are connected. The columns in the worksheet include: Service application. This column lists all of the service applications. You can add service applications based on your SharePoint 2010 SKU and any third-party service applications that you use. Description. This column gives a brief description of the service functionality. Although this may not be necessary for an experienced architect, it makes it
2-49
easier to map services against business requirements. You may add dependencies here to assist less experienced IT staff. Service application instances. This column enumerates the number of instances for each service application. Make sure that you have all of the instances that are necessary for isolation and performance. Web application proxy groups. This column lists the Web application proxy groups. For each Web application that uses a service application, you should identify the name of the proxy group. For most proxy groups, this should be the Default option. However, you can also specify the custom groups with their associated Web application. There may be a series of these columns. Proposed database names. This column lists the names of the service application databases that you intend to create. For each service application that you create, you should name the associated database or databases. Remember that multiple instances can share a common database set, so if you want to isolate service applications at the database level, you must provide names for each service instance. You may need to consult with your DBA to ensure that you select names that fit with any existing standard.
2-50
Lab: Planning a Service Application Architecture
Exercise 1: Designing a Logical Architecture

Scenario
The logical design for the Contoso, Ltd environment has been signed off, so you now need to define the service applications that are necessary to service the business requirements. Your team must also test part of the design by creating Managed Metadata Service instances for Contoso, Ltd and Contoso Research on the test environment. The main tasks for this exercise are as follows: 1. 2. Read the supporting information. Complete the Service Applications Planning worksheet.
2-51

1. 2. 3. Read the lab scenario. Log on to 10231A-NYC-DC1-02 as CONTOSO\Ed with the password Pa$$w0rd. In the E:\Labfiles\Lab02\Starter folder, read the Contoso Business Requirements.docx and Logical Architecture Requirements.docx files.
Task 2: Complete the Service Applications Planning worksheet

In the E:\Labfiles\Lab02 \Starter folder, complete the SharePoint 2010 Service Applications Planning worksheet.xlsx file.
Exercise 2: Creating Service Applications and Assigning Proxy Groups

Scenario
To assess part of your design, you must create some of the service application components for user acceptance testing. The main tasks for this exercise are as follows: 1. 2. Create Managed Metadata Service applications. Associate a service application with a custom proxy group.
Task 1: Create Managed Metadata Service applications

1. Use the Application Management page to create a Managed Metadata Service application by using the following configuration inputs: 2. Name: MMS_Default Database name: TermStore_Default Application Pool: SharePoint Web Services Default
Use the Application Management page to create a Managed Metadata Service application by using the following configuration inputs: Name: MMS_Research Database name: TermStore_Research
2-52
Application Pool: SharePoint Web Services Default
Task 2: Associate a service application with a custom proxy group

Use the Application Management page to associate the SharePoint Research Web application with the MMS_Research service application.
2-53
Review Questions
1. 2. 3. What are the key differences between the service application architectures in SharePoint 2010 and Office SharePoint Server 2007? What is a proxy? What is a proxy group?
Best Practices Related to Service Applications

Supplement or modify the following best practices for your own work situations Minimize the number of service applications that you deploy to match business requirements. This saves server resources. Check for service application dependencies. Assess requirements to define the number of instances that are necessary. This requires ongoing monitoring of performance.
Planning for Performance and Capacity
3-1
Module 3
Contents:
Lesson 1: Principles of Performance Planning Lesson 2: Designing for Performance Lesson 3: Principles of Capacity Planning Lesson 4: Designing for Capacity Lab: Planning for Performance and Capacity 3-3 3-17 3-41 3-52 3-65
3-2
Module Overview
Planning for performance and capacity is an important part of designing your Microsoft SharePoint 2010 deployment. If your SharePoint environment does not meet the performance needs or expectations of your users, there could be significant resistance to the adoption of the solution. If you do plan enough storage, the solution will quickly run out of space to expand, and this will delay or prevent adoption of the solution.
Objectives
After completing this module, you will be able to: Describe the principles of designing to maximize performance. Create a SharePoint 2010 performance design that mitigates performance problems. Describe how capacity planning affects the design of a SharePoint 2010 implementation. Create a SharePoint 2010 farm design that caters for current and future capacity demands.
3-3
Lesson 1
Principles of Performance Planning
Before you create your performance plan, it is important to understand how to measure performance of a SharePoint 2010 server farm. Your choice of features to implement will also affect performance. You will need to estimate the number of servers that your farm requires before performing testing to verify that the farm meets the performance expectations of your organization.
Objectives
After completing this lesson, you will be able to: Identify elements of performance design. Identify SharePoint 2010 server roles. Identify the performance characteristics of Web Front End (WFE) servers. Identify the performance characteristics of application servers. Identify the performance characteristics of search servers. Identify the performance characteristics of database servers.
3-4
Discussion: Performance Considerations
Key Points
When you consider a SharePoint 2010 solution, the design must achieve the performance requirements that the business specifies. Question: How can you measure SharePoint 2010 performance? Question: Which elements of a solution will affect performance? Question: Which tools can you use to measure performance? Question: When should you improve performance? Question: How can you identify that a performance improvement has been achieved?
3-5
SharePoint 2010 Server Roles
Key Points
When you plan and design a SharePoint 2010 solution, it is important to consider architectural elements of the solution to understand the impact of these elements on the design. SharePoint farms have three operational tiers of services that servers in different roles can perform. The following sections describe these tiers.
Web Front End Servers

WFE servers render the Web page content and return it to the client that requests content.
Application Servers
The application server role relates to the provision of services in the farm. Application servers host service applications, including: Search Service (query and crawl) User Profile Service Business Data Connectivity Service
3-6
Web Analytics Service Managed Metadata Service Excel Services Application Access Service Visio Graphics Service Word Automation Services Performance Point Service Application Usage and Health Data Collection Service State Service Secure Store Service
Database Servers
The database server role describes the computer or computers running Microsoft SQL Server that hold the following types of database: Farm configuration Search (administration, property, and crawl databases) Business Data Connectivity Managed Metadata Secure Store State User Profile Profile Synchronization Social Tagging Usage and Health Data Collection
3-7
Performance of Web Front End Servers
Key Points
WFE servers form the SharePoint connection point for clients that request content or services. This means that all client requests place some load on the WFE servers. WFE servers render pages before returning requested pages to a browser. In small farms, WFE servers often perform application roles in addition to the WFE role. WFE servers do not require large quantities of disk storage, but rely heavily on processor and memory for performance. The following table describes the processor and memory load characteristics for WFE servers.
Service application or feature SharePoint Foundation Service Timer Service Logging Service CPU load High Medium Medium Memory load High Medium Medium
3-8
Service application or feature User Profile Service Word Viewing Service PowerPoint Service Excel Calculation Service Visio Service Access Service Managed Metadata Service Web Analytics Service Business Connection Service InfoPath Forms Service Word Conversion Service PerformancePoint Service Sandboxed Solutions Workflow Capabilities
CPU load Low Low Medium Medium Low Low Low Low Medium Medium Low Medium Low High
Memory load Medium Low Medium Low Low Low Medium Low Medium Medium Low Medium Low High
Note: These load characteristics exist even when all service applications are running on dedicated application servers. For example, the Excel Calculation Service will increase CPU usage on the WFE server, even if you have an application server dedicated to running Excel Services.
You can use the table as a guideline to help when you calculate workload for WFE servers. Use the following information when calculating server workload: Consider that medium-cost CPU operations are three times heavier on workload than low-cost CPU operations. Consider that high-cost CPU operations are five times heavier on workload than low-cost CPU operations.
3-9
To improve performance of page rendering and client access, you can add more WFE servers to the farm and implement network load balancing.
Additional Reading
For more information about sizing for SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200850&clcid=0x409.
3-10
Performance of Application Servers
Key Points
Application servers host service applications. Service applications offer a more flexible approach to farm services than previous versions of Microsoft Office SharePoint; you now have more options for controlling which servers in the farm run specific service applications. Different service applications have different workload profiles, but you can dedicate specific servers to specific service applications. You can also scale out by specifying multiple servers for a specific service application. Different service applications have different workload profiles, but most application services do not require local storage on the application server. The main hardware requirements for application servers are processor and memory. The following table describes the processor and memory load characteristics for application servers.
3-11
Service application or feature SharePoint Foundation Service Timer Service Logging Service User Profile Service Word Viewing Service PowerPoint Service Excel Calculation Service Visio Service Access Service Managed Metadata Service Web Analytics Service Business Connection Service InfoPath Forms Service Word Conversion Service PerformancePoint Service Sandboxed Solutions Workflow Capabilities
CPU load None Medium None Medium High High Medium High High Medium None High Medium High High High None
Memory load None Medium None Medium Medium Medium High High Medium Medium None High Medium Medium High High None
Generally, for best performance, server roles should not share service applications with a high load. Consider that some service applications will also increase the workload on the WFE servers.
Additional Reading
For more information about performance test results and recommendations, see http://go.microsoft.com/fwlink/?LinkID=201227&clcid=0x409.
3-12
Performance of Search Servers
Key Points
Search is typically a significant benefit of implementing SharePoint 2010, but it places a large workload burden on the farm. When you consider farm performance, you must often consider search performance specifically in the context of the farm. Search servers can perform two functions: The crawl component crawls and indexes content primarily in the SharePoint content databases, although it can also index other types of storage repository. The crawl role builds the index and submits index updates to the search query role. Crawl components aggressively use CPU bandwidth. Optimally, a given crawl component can utilize four CPU cores. Memory is not as critical for the crawl component. The query component responds to user search requests. When users enter a search in a SharePoint site, SharePoint 2010 submits the query to a server that hosts the query role to return a result set. All servers that host the query role have a copy of the index that the crawl role generates. However, additional
3-13
search databases also hold specific search information. The query role typically has high processor and memory requirements.
Note: A single search server can perform both crawl and query functions.
In addition, the Search service has a significant impact on database servers. The Search service places a high load on CPU, input/output (I/O), and storage components. Crawl databases aggressively use I/O bandwidth. A crawl database needs 3,500 I/O operations per second (IOps) for crawling activities; it will consume as much as 6,000 IOPS, based on the available bandwidth. Question: Can you spread the crawl component across multiple servers in a farm?
3-14
Performance of Database Servers
Key Points
Database servers store most SharePoint content and most SharePoint configuration data. Not all service applications affect database servers, because some service applications do not require databases. However, storage access times and storage capacity are a key focus for the role. The following table describes the processor, I/O load, and storage characteristics for database servers.
Service application SharePoint Foundation Service Timer Service Logging Service User Profile Service Word Viewing Service CPU load Medium None Medium High None I/O load High None High High None Storage High None High Medium None
3-15
Service application PowerPoint Service Excel Calculation Service Visio Service Access Service Managed Metadata Service Web Analytics Service Business Connection Service InfoPath Forms Service Word Conversion Service PerformancePoint Service Sandboxed Solutions Workflow Capabilities
CPU load None None Low Low Low High None Low Low Low None None
I/O load None None Low Low Low High None Low Low Low None None
Storage None None Low Low Medium High None Low Low Low None None
Disk Storage
Disk storage types and redundant array of independent disks (RAID) configuration can have a significant impact on the performance of database servers. Direct attached storage (DAS) is a configuration where a storage controller without a network interface connects the server and disk hardware. DAS typically uses Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), or Serial ATA (SATA) disks. A storage area network (SAN) connects server hardware to disk hardware over a dedicated network. This can be an Ethernet-based network or a Fibre Channel based network. SAN storage appears to the operating system as locally attached disks. SANs offer high-speed, high-capacity storage with additional capabilities, such as the ability to support SQL Server clusters. However, they create a significant cost increase over DAS. Network attached storage (NAS) is a self-contained storage device that a server or client can access over the network, typically through traditional file-share methods.
3-16
Note: Only content databases that use remote binary large object (BLOB) storage support NAS storage. Any network storage architecture must return the first byte of data within 20 ms.
You can use different disk types and different RAID configurations to support specific performance requirements. SAS disks typically support faster access times, although specific RAID configurationssuch as RAID 1, RAID 5, or RAID 10can also affect read or write access times.
Note: You should consult the guidelines that the storage hardware manufacturer provides to determine the RAID configuration effect on performance.
If you experience performance or storage bottlenecks with the database server role, you can add more database servers to the farm and spread your database requirements across multiple servers. Question: Why should you consider RAID storage options for your database and transaction log file storage?
3-17
Lesson 2
Designing for Performance
It is important to recognize which performance factors you must measure to plan a SharePoint Server 2010 deployment that meets the performance requirements of your organization. After modeling performance, you must also understand how to configure your farm design and topology to change the performance profile of the farm.
Objectives
After completing this lesson, you will be able to: Map business requirements to solution performance. Map logical architecture and service application design to performance. Identify scaling options for improving SharePoint farm performance. Select a suitable topology for a SharePoint farm. Monitor SharePoint 2010 server performance.
3-18
Identify steps in performance management modeling. Identify tools for performing performance testing. Identify caching options for performance improvement in SharePoint 2010.
3-19
Mapping Business Requirements to Performance
Key Points
There are four major aspects to sizing performance. The following sections describe these aspects.
Latency
Latency is the time that elapses between the user performing an action and the client receivingand possibly displayingthe data. For example, it is the time that elapses between the user clicking a link and the client displaying the destination page. Latency typically includes the time from the client sending a request to the server; the server processing the client request; the server sending a response to the client; and the client processing or rendering the response. SharePoint 2010 latency can suffer in many different areas, including: Network latency, also referred to as round trip time (RTT). Available network bandwidth, which affects how long it takes to send back the whole of the response.
3-20
Uncompressed data transmission. Custom code elements, such as Web Parts or features that are not well optimized.
You can only determine the server processing and client rendering elements of latency through performance testing. However, you may have access to case studies that can provide a benchmark to assist in determining general requirements.
Throughput
Throughput is the number of requests that a server farm is able to process in a fixed period. To create a SharePoint farm solution that satisfies user requirements, you should: Estimate the expected load. Conduct performance testing against the suggested configuration.
You will often need to calculate workload to estimate the number of servers that you require for adequate throughput. You can calculate workload by using a worksheet to identify the number of concurrent users and the average number of requests each day. The following table outlines an example worksheet.
Workload characteristics Total number of users (Tu) Total number of unique users each day Concurrency rate (Cr) Requests each day by each user Peak usage ratio (Pu) Hours in the business day (H) Value
You can then apply the following formula to estimate the number of requests per second: Requests per second = (Tu Cr Pu Rd) (H 3600) In this formula, Tu is the total number of users, Cr is the average concurrent number of users, Pu is the peak usage ratio, Rd is the average number of requests
3-21
each day by each user, and H is the number of working hours in the day. 3,600 is the factor to convert hours into seconds.
Note: You should use peak user loadfor example, the number of concurrent users at peak timesto size the SharePoint farm to cope with peak performance requirements.
You can then estimate the different types of request to factor in medium or highcost CPU activities, which have a higher impact on workload. Use the following formula to estimate weighted requests per second: Medium-cost CPU operations = 3 low-cost CPU operations High-cost CPU operations = 5 low-cost CPU operations
Data Scale
Data scale is the corpus of data or content that the server farm holds. Generally, greater volumes of data reduce throughput, but data distribution across different servers and storage media can also have an effect. You can calculate data scale based on certain information about content storage, or you can estimate data scale based on the storage requirements in your current environment. Certain data operations can also affect throughput or latency because SQL Server invokes database locks to prevent conflicting operations.
Reliability
Typically, many administrators consider reliability as uptime. However, in the context of performance management, reliability is a measure of the time for which the farm can meet all performance targets. This should include coverage of peak load times. Peak load times may be when the highest number of users are logged on, or when search crawls are running, or when backup tasks are running. Many organizations will have a reliability target that is expressed as a number of nines. The following table shows some example reliability figures with the corresponding calculated time value.
Reliability value 99 percent (two nines) 99.9 percent (three nines) 99.99 percent (four nines) Unacceptable performance time each month 7 hours 43 minutes 4 minutes
3-22
Question: How can you determine RTT for a network link?
Additional Reading
For more information about capacity planning for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200854&clcid=0x409.
3-23
Mapping Logical Architecture and Service Application Design to Performance
Key Points
When you plan a SharePoint solution, it is important to understand the effect of the logical architecture design on performance. Logical architecture choices such as the number of Web applications or the number of site collections in a database can have a dramatic effect on performance. In SharePoint 2010, there are specific restrictions known as limits or boundaries: Limits. These are values beyond which users may experience degraded performance. You can exceed threshold limits with a supported configuration, although performance may be degraded. A configuration is not supported if you exceed a supported limit. Boundaries. These are hard-coded maximum values that the system cannot exceed.
SharePoint solution designs must take account of these limits to maximize performance.
3-24
The following table shows Web application limits.

Limit Content database Maximum value 300 for each Web application 5 for each Web application 20 for each Web application 10 for each Web server Restriction type Supported Limit
Zone Managed path
Boundary Supported Limit
Application pools
Supported Limit
The following table shows site collection limits.

Limit Web site Maximum value 250,000 for each site collection 200 gigabytes (GB) Restriction type Supported Limit
Site collection size (unless it is the only site collection in the database) List view threshold
Supported Limit
5,000 items (warning at 3,000 items)
Threshold Limit
Note: SharePoint 2010 can exceed supported limits, at the risk of degraded performance and an unsupported farm configuration. SharePoint 2010 cannot exceed stated boundaries. SharePoint 2010 can exceed threshold limits in a supported configuration, but at the risk of degraded performance.
Service application design can affect the required performance of the design by introducing additional hardware requirements. You can dedicate one or more application servers to a service application if that service application requires additional performance or places a high load on the farm. Question: How can an organization create a single SharePoint farm to hold 1 terabyte of collaborative data, given that the content database size limit is 200 GB?
3-25
Additional Reading
For more information about the software boundaries and limits for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200855&clcid=0x409.
3-26
Scalability of SharePoint 2010
Key Points
You can scale SharePoint farms to meet performance targets in two different ways: Scale up. Scaling up involves changing the server hardware configuration to increase the workload that a single server can accommodate. For example, you can increase the number of processor cores in a server, increase the amount of memory in the server, or upgrade the disk subsystem to use faster storage. Scale out. Scaling out involves adding more servers to the farm to achieve capacity or performance targets. For example, you can add more database servers to dedicate the search database load to another server.
Question: In addition to extra hardware costs, what other cost does scaling out incur?
3-27
Selecting a Farm Topology
Key Points
It is important to consider farm size and topology carefully when you size a SharePoint 2010 solution for performance and capacity. Farm topologies for SharePoint 2010 fall broadly into three categories: Small farm. A small SharePoint farm typically has two or three tiers made up from up to five servers. Typically, there is a single database server, and WFE servers may also perform service application roles. A two-tier, three-server farm can serve relatively low usage load (a few requests per minute to a few requests per second (RPS)) and a volume of data in the region of tens of gigabytes. Medium farm. A topology for a medium SharePoint farm typically has three tiers, with more than six servers. There may be multiple database servers, multiple search servers, and application servers that are dedicated to specific service applications. Multiple WFE servers enable many concurrent user requests. A medium-size farm can serve a usage load of a few tens of RPS and a data volume up to 1 terabyte.
3-28
Large farm. A topology for a large SharePoint farm typically employs in excess of 1012 servers that are arranged in three tiers. In a large farm, you often logically group servers according to the applications that the servers host. For example, a group of three servers hosting Microsoft InfoPath forms, or a group of two crawl servers. A large farm can serve usage loads of hundreds of RPS and data storage of tens of terabytes.
Additional Reading
For more information about topologies for SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200856&clcid=0x409.
3-29
Monitoring Performance
Key Points
To size a solution correctly from a performance perspective, you should perform monitoring of the system under load to ascertain performance characteristics, identify bottlenecks, and establish the capability of the solution to meet business requirements. You can use the Performance Monitor tool in Windows Server 2008 and Windows Server 2008 R2 to capture performance information from performance objects and counters. Performance objects can include hardware components such as processor or memory. They can also include software components such as Windows operating system subsystems or the Microsoft .NET Framework. You can also add the performance counters that you need to monitor to the SharePoint Usage and Health Data Collection database, which can then provide a single point for health and performance data. You do this by using the AddSPDiagnosticsPerformanceCounter Windows PowerShell cmdlet. You should capture initial performance statistics under peak load to create a baseline for how the system performs. You should then regularly revisit the
3-30
performance information for the live system. This will enable you to capture trend data and identify any areas for performance improvement, if required. The following table describes the system performance counters that you should monitor on any Web server.
Counter % Processor Time
Object Processor
Description This shows processor usage over a period of time. If this is consistently too high, you may find performance is adversely affected. Remember to count "Total" in multiprocessor systems. You can also measure the usage on each processor to ensure balanced performance between cores. This shows the average number of both read and write requests that were queued for the selected disk during the sample interval. A bigger disk queue length may not be a problem as long as disk reads/writes are not suffering and the system is working in a steady state without increasing the queue length. This shows the average number of read requests that are queued. This shows the average number of write requests that are queued. This shows the number of reads to disk per second. This shows the number of writes to disk per second. This shows the amount of physical memory that is available for allocation. Insufficient memory will lead to excessive use of the page file and an increase in the number of page faults per second. This shows the rate at which faults occur when a page is sought in the file system cache and is not found. This may be a soft fault, when the page is found in memory, or a hard fault, when the page is on disk.
- Avg. Disk Queue Length
Disk
Avg. Disk Read Queue Length Avg. Disk Write Queue Length Disk Reads/sec Disk Writes/sec - Available Mbytes
Disk
Disk
Disk Disk Memory
- Cache Faults/sec
Memory
3-31
Counter
Object
Description The effective use of the cache for read and write operations can have a significant effect on server performance. You must monitor for increased cache failures, which are indicated by a reduction in the Async Fast Reads/sec or Read Aheads/sec counters.
- Pages/sec
Memory
This shows the rate at which pages are read from or written to disk to resolve hard page faults. If this rises, it indicates system-wide performance problems. The server paging file, sometimes called the swapfile, holds virtual memory addresses on disk. Page faults occur when a process has to stop and wait while required virtual resources are retrieved from disk into memory. These will be more frequent if the physical memory is inadequate. This is the rate at which data is sent and received via the network interface card. You may need to investigate further if this rate is over 40-50 percent of network capacity. To fine-tune your investigation, monitor Bytes received/sec and Bytes Sent/sec counters. This indicates the current size (in bytes) of the working set for a given process. This memory is reserved for the process, even if it is not in use. This indicates the percentage of processor time that a given process uses. This shows the current number of threads.
- % Used and % Used Peak
Paging File
- Total Bytes/sec
Network Interface
- Working Set
Process
- % Processor Time Thread Count (_Total) Requests Total
Process
Process
ASP.NET
This shows the total number of requests since the service was started. Microsoft SharePoint Foundation 2010 provides the building blocks for HTML pages that are rendered in the user browser over HTTP. This counter shows the number of requests that are waiting to be processed.
Requests Queued
ASP.NET
3-32
Counter Request Wait Time
Object ASP.NET
Description This shows the number of milliseconds that the most recent request waited in the queue for processing. As the number of wait events increases, users will experience degraded page-rendering performance. This shows the total number of requests that were not performed because of insufficient server resources to process them. This counter represents the number of requests that return a 503 HTTP status code, indicating that the server is too busy. This shows the number of requests that are currently running. This shows the number of requests that are performed each second. This represents the current throughput of the application. Under constant load, this number should remain within a certain range, barring other server work (such as garbage collection or external server tools).
Requests Rejected
ASP.NET
Requests Executing (_Total) Requests/Sec (_Total)
ASP.NET
ASP.NET
The following table describes the system performance counters that you should monitor on a computer running SQL Server.
Counter User Connections
Object SQLServer:General Statistics
Description This shows the amount of user connections on your instance of SQL Server. If you see this number rise by 500 percent from your baseline, you may see a performance reduction.
SQLServer:Databases This object provides counters to monitor bulk copy operations, backup and restore throughput, and transaction log activities. Monitor transactions and the transaction log to determine how much user activity is occurring in the database and how full the transaction log is becoming. The amount of user activity can determine the
3-33
Counter
Object
Description performance of the database and affect log size, locking, and replication. Monitoring low-level log activity to gauge user activity and resource usage can help you to identify performance bottlenecks.
Transactions/sec
SQLServer:Databases This shows the amount of transactions on a given database or on the entire SQL Server instance per second. This number is to help you create a baseline and troubleshoot issues. SQLServer:Locks This shows the number of deadlocks on the computer running SQL Server per second. This should be 0. This shows the average amount of wait time for each lock request that resulted in a wait. This shows the total wait time for locks in the last second. This shows the number of locks per second that could not be satisfied immediately and had to wait for resources. This shows the average latch wait time for latch requests that had to wait. This shows the number of latch requests per second that could not be granted immediately. This indicates the number of times the compile code path is entered per second. This indicates the number of times statement recompiles are triggered per second. This indicates the ratio between cache hits and lookups for plans.
Number of Deadlocks/sec
Average Wait Time (ms)
SQLServer:Locks
Lock Wait Time (ms) Lock Waits/sec
SQLServer:Locks
SQLServer:Locks
Average Latch Wait Time (ms) Latch Waits/sec
SQLServer:Latches
SQLServer:Latches
SQL Compilations/sec SQL ReCompilations/sec
SQLServer:SQL Statistics SQLServer:SQL Statistics
Cache Hit Ratio
SQLServer:Plan Cache
3-34
Counter Buffer Cache Hit Ratio
Object SQLServer:Buffer Manager
Description This shows the percentage of pages found in the buffer cache without having to read from disk. The ratio is the total number of cache hits divided by the total number of cache lookups since an instance of SQL Server was started.
Note: The SQL Server performance counters are included here for the sake of completeness. Many SharePoint architects will not be SQL Server performance experts. You may want to discuss SQL Server performance issues with an experienced SQL Server database administrator (DBA).
Question: What are the four common hardware components to monitor on a server?
Additional Reading
For more information about how to monitor and maintain SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200857&clcid=0x409.
3-35
Performance Management Modeling in SharePoint 2010
Key Points
Performance management modeling for SharePoint 2010 includes five key steps: 1. Model. Model the farm environment that you require by establishing the elements or features that you want your solution to provide. Also, determine any required measures such as performance and reliability. The modeling exercise should create: 2. 3. Expected workload and dataset (volume of data). Farm performance and reliability targets.
Design. Design the farm by using the data from the first step. The design step should create logical and physical architecture designs. Pilot, test, and optimize. Deploy a pilot environment and conduct testing against performance targets. Where necessary, optimize the deployment to meet performance targets or consider revising the solution (for example, change the solution scope or revise the topology). Deploy. Deploy the established solution to the production environment.
4.
3-36
5.
Monitor and maintain. Implement monitoring of capacity and performance, identify trends and bottlenecks, and implement maintenance activities when required.
While you initially plan your SharePoint farm, you will use the first three steps to identify performance targets, design the farm, and perform testing to determine whether the design meets the required performance targets.
Note: Workload describes the demand that the system must sustain. Workload typically uses the label RPS to describe demand on the server farm. It is most common to measure RPS by using all requests in the Internet Information Services (IIS) log except the Authentication handshake requests (401HTTP status). You do not count these because they bias the calculated RPS figure.
Question: How can you identify SharePoint performance issues before you create your production environment? Question: What resolution steps can you take to resolve a performance issue at the pilot phase?
Additional Reading
For more information about capacity planning for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200858&clcid=0x409.
3-37
Performance Testing in SharePoint 2010
Key Points
You can use several tools to help you to perform performance testing against your SharePoint servers. One of the most comprehensive load-testing tools for SharePoint environments is Microsoft Visual Studio 2010. The following table describes load-testing configuration options for Visual Studio 2010.
Configuration Local load generation Description In this configuration, the client computer running Visual Studio generates all of the Web requests for the load test. The load test is limited to 250 virtual users, and the test only uses one core of the client CPU. In this configuration, you distribute the test controller and test agents across different computers to scale out the load agents and increase the test load. You must install virtual user packs on the test controller computer to enable testing. This configuration enables the use of all
Distributed test controller and test agents, optionally stacked with client computer.
3-38
Configuration
Description CPU cores on the load agent computers. This configuration is suitable where a team will be performing testing. Optionally, you can use the client computer running Visual Studio as the test controller computer. This configuration enables all cores and more than 250 virtual users on the client computer, but is only recommended for scenarios where an individual will perform testing.
After you have chosen your configuration for Visual Studio, you should create a new project in Visual Studio. The project requires configuration of two elements: Web tests. Web tests are an instruction for the Visual Studio load test engine to retrieve a specific Web page or URL. Load tests. Load tests are a collection of tests to perform as a batch. Load tests typically include a number of Web tests and enable you to configure ratios between the individual Web tests included in the load test.
Note: Visual Studio load-test projects can include a think time variable, which is intended to mirror the behavior of users browsing a Web site, such as pausing between pages. For the test to return a raw RPS value, it is recommended that you ignore this feature.
In addition, you can configure Visual Studio to capture performance counters from the servers that you are testing during the test. You must add any counters that you want to capture to the load-test project. You can also specify the duration for the load test. You should run the load test over a period that will ensure that all operational factors are included, such as timer jobs or index crawls.
Note: You can use the Load Testing Toolkit (LTK) to test whether an existing Office SharePoint 2007 topology can sustain an upgrade to SharePoint Server 2010 with the same load. The LTK is available as part of the SharePoint 2010 Administration Toolkit.
3-39
Caching in SharePoint 2010
Key Points
SharePoint 2010 has several methods of caching data and objects to help improve performance for the end user. When a client requests a page, a copy of the page is stored temporarily in the output cache. Although the duration of the cache is typically small (the default is 60 seconds), this can greatly assist the performance of WFE servers and reduce latency. Cache profiles are available so that site administrators can control the output cache behavior. Administrators can also determine whether different users, such as content editors, receive cached pages. You can adjust the output cache at the site, site collection, or Web application level. SharePoint 2010 uses the object cache to temporarily store objects such as lists, libraries, or page layouts on the WFE server. This enables the WFE server to render pages more quickly, reducing the amount of data that is required from the SQL Server databases. You can adjust the size of the object cache at the site collection and Web application levels.
3-40
The page output and object caches are memory-based and will require testing to determine the optimum setting for a site or site collection.
Note: The page output cache and the object cache only take effect on sites that have the Publishing feature enabled.
SharePoint 2010 has a BLOB cache that temporarily stores digital assets, such as image or media files, but you can use it with any file type. Using the BLOB cache in conjunction with the Bit Rate Throttling feature in IIS 7.0 also enables the progressive download feature for digital assets. Progressive download enables the download of media files in chunks of data, and playback can start after the client downloads the first chunk rather than the whole file. You can enable and control the size of the BLOB cache at the Web application level. The default size is 10 GB and the default setting is disabled. For deployments where you want to make use of digital assets, you should enable the BLOB cache for the relevant Web applications. You should perform the change on all of the Web servers that host the specific Web application. If there are large quantities of digital assets or they are heavily used, consider increasing the size of the BLOB cache. Alternatively, you can dedicate a specific Web application to media files, such as digital assets, and configure a much larger BLOB cache for that Web application.
Note: The page out cache and the object cache are memory-based caches on the WFE servers. The BLOB cache is a disk-based cache on the WFE servers.
Question: Where do you configure the settings for the BLOB cache?
Additional Reading
For more information about cache settings operations in SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200859&clcid=0x409. For more information about planning for caching in SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=201228&clcid=0x409.
3-41
Lesson 3
Principles of Capacity Planning
Your initial planning for a SharePoint Server 2010 deployment must include sufficient storage capacity to accommodate the content that users will store in SharePoint storage repositories, and the additional needs of the SharePoint farm, including administrative and service application requirements.
Objectives
After completing this lesson, you will be able to: Identify capacity requirements. Identify architecture and storage elements in SharePoint 2010 that affect capacity planning. Identify supporting environmental factors that affect capacity planning in SharePoint 2010. Identify storage and database options for a SharePoint farm. Identify content considerations that affect capacity planning.
3-42
Capacity in a Business Context
Key Points
When IT professionals discuss capacity, storage is typically at the forefront of that discussion. However, it is important that you consider other aspects of capacity, such as network capacity or performance capacity. SharePoint 2010 stores most content in SQL Server databases; therefore, capacity planning for storage involves a large amount of database planning. It is important that you understand content characteristics to plan for the corpus (the total amount of data to store in SharePoint 2010). You should also understand how logical architecture fits together with database storage. This will enable you to plan for the right number of databases, split content among databases correctly, and plan for database growth. You must also consider network capacity, particularly in terms of client access connections to WFE serversand application servers in some cases. New features in SharePoint 2010 such as Office Web Apps and digital asset storage and playback introduce additional network traffic requirements over previous versions of Office SharePoint.
3-43
Finally, consider the business requirements for the solution. What are the performance requirements? Will the solution have performance headroom to enable growth in users with the same performance requirements?
3-44
Principles of Capacity Planning for SharePoint 2010
Key Points
When you size capacity requirements for storage, it is important to identify how different storage requirements and different data types will affect database and site collection design. SharePoint 2010 has certain boundaries and limits that affect storage choices, which include: An individual SharePoint content database should not grow beyond the supported limit of 200 GB. An individual file that you store in SharePoint 2010 cannot be larger than the boundary limit of 2 GB. A single list row cannot exceed the boundary limit of 8,000 bytes per row.
If you have large quantities of data (greater than 100 GB) to store in SharePoint content databases, you must consider how to arrange that data in multiple site collections. This is because site collections cannot span separate content databases.
3-45
If you want to make quantities of files available to SharePoint 2010 users, you can store some contentfor example, archive or static filesin other content sources, such as a network file share. You can make this content available to users through search or links in SharePoint 2010. If you plan to store and manage digital assets, you may require extra storage. Digital assets such as media files are traditionally much larger than documents. Consider that metadata also requires storage in the content database and adds to the size of the search database. You must also plan your search capacity requirements, because there are additional limits that are associated with search indexes. These limits include the number of crawl databases and the maximum index item limit.
Additional Reading
For more information about the software boundaries and limits of SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200860&clcid=0x409. For more information about storage and SQL Server space and I/O requirements, http://go.microsoft.com/fwlink/?LinkID=201229&clcid=0x409.
3-46
Principles of Capacity Planning for Supporting Elements
Key Points
In addition to planning capacity requirements for the elements of the solution that are specific to SharePoint 2010, you must also plan the capacity of supporting elements in the network environment. You should place domain controllers on the same high-speed network segment as the SharePoint farm, to support logon requests at the SharePoint farm or to support a connection for importing user profile data from the Active Directory directory service. If users will be connecting over wide area network (WAN) or Internet links, you should consider the quantity of data that clients transmit and receive over the link and the number of concurrent users on the link. SharePoint 2010 introduces new features that affect network traffic. The following table lists the new features, with an overview of the traffic and payload quantities.
3-47
Client Office Web Apps PowerPoint Web broadcast Microsoft Word 2010 and Microsoft PowerPoint 2010 client applications Microsoft OneNote client application Outlook Social Connector Microsoft SharePoint Workspace 2010
Traffic High High Medium
Payload Medium Low Low
High Medium High
High Medium Medium
In addition to planning capacity for SharePoint content storage, you must plan capacity for additional SQL Server requirements, such as transaction log storage. SQL Server creates and expands transaction logs as additional operations occur to content, such as adding new content or making changes to existing content. You can manage transaction logs in two different ways: Change the database model from full to simple. The simple database model automatically limits transaction log size by reusing space from committed transactions. Regularly back up the databases. During a SQL Serveraware backup task, transaction log data is backed up and the transaction log is truncated to free space on the transaction log disk. This option requires enough disk space to enable the transaction log to grow sufficiently between backups.
Note: The database model also affects the recoverability of content databases and advanced features such as database mirroring. If you back up a database under the simple model, you can only restore the database to the time of the backup. If you back up a database under the full model, you have the capability to restore a database to the time of failure. The full model is required to support database mirroring.
3-48
How Capacity Planning Affects Farm Design
Key Points
After you have established the features that you want to provide in the solution and the dataset that you want to support, you must consider the business requirements from a capacity standpoint to make decisions about storage requirements. For database servers, you must decide on the number of databases that you require. Specific service applications, such as the Managed Metadata Service or the User Profile Service, require additional databases. In addition, your content databases are constrained by the following architectural limits in SharePoint 2010: A single site collection should not be larger than 100 GB, unless it is the only site collection in a database. A single content database should not be larger than 200 GB. A site collection cannot span multiple databases.
These limits will drive the choice that you make about the number of site collections and databases that you require, based on the quantity of storage that is required in SharePoint 2010. In addition, for management purposes, such as
3-49
backup and restore, you may choose to implement a larger number of smaller databases rather than a smaller number of large databases. You must also consider the storage hardware requirements. Your choice of RAID implementation will affect the quantity of disks that you require and the cost of your solution. If you plan a mirrored SQL Server implementation, you must duplicate your database and transaction log storage. If you plan to use SAN for storage, correctly size the SAN volumes, including transaction logs and configuration and service application databases where appropriate.
Note: It is recommended that your plan includes sufficient free space to enable database growth over time. The recommended value of free space on the content database disks should be equal to the database size, after you populate the database with the planned content.
After you have established your initial capacity requirements, create a baseline and monitor storage over time to identify trends in storage growth. Question: Why should database size typically be kept below 200 GB for each database?
3-50
Planning for Content Characteristics
Key Points
Different types of content and the requirements for that content storage in SharePoint can significantly increase the storage capacity requirement for a SharePoint solution.
Documents
Typically, documents take up the same amount of space in SharePoint 2010 that they take up in a traditional file share. However, additional feature requirements can significantly increase the storage burden for documents or digital assets.
Digital Assets
Previous versions of Microsoft Office SharePoint had few digital asset capabilities. With the improvements in SharePoint 2010, many organizations may consider storing digital assets in SharePoint content databases.
Version History
Document libraries can store historic versions of documents each time a user makes a change. Historic document versions take up an additional amount of
3-51
storage according to the historic version size. This means that a document with 10 versions that are all approximately 10 MB in size takes up 100 MB in the content database.
Metadata
Adding metadata to documents increases the size of the content database and the search properties database. If you do not know the quantity of metadata, for planning purposes, use an estimate of 10 KB for each item.
Recycle Bin Behavior

When you consider database file size, you must take account of the SharePoint 2010 Recycle Bin behavior. The second-stage Recycle Bin uses an additional percentage of the site collection quota. Therefore, for a database with a single site collection, if the second stage Recycle Bin is set to use 50 percent of the site collection quota and the site collection quota is set to 50 GB, the database file could grow to be 75 GB in size.
3-52
Lesson 4
Designing for Capacity
You must plan the capacity targets and how you will achieve them for all SharePoint data storage. If you do not plan enough storage, including storage for growth, your SharePoint farm may not be able to manage user demands. In addition to calculating the storage requirements for content databases, this will include planning the capacity of configuration databases, databases for service applications, search-related databases, and index partitions.
Objectives
After completing this lesson, you will be able to: Design capacity for configuration databases. Design capacity for service application databases. Design capacity for content databases. Design capacity for search databases and index partitions. Plan for remote BLOB storage for SharePoint 2010.
3-53
Designing Capacity for Configuration Databases
Key Points
There are two key configuration databases for a SharePoint 2010 server farm: Configuration database. The configuration database holds the farm configuration data, such as number of Web applications, managed path configuration, and farm membership. The configuration database is typically less than 1 GB in size, but log file growth can be significant over time as you make more configuration changes to the farm. To mitigate the log growth, you should consider regular SQL Server backups of the configuration database or changing the database model to simple. The configuration database has a readintensive usage profile. Central Administration database. The Central Administration database holds the content for the Central Administration site collection. This is typically less than 1 GB in size, unless you deploy Microsoft PowerPivot in the farm. If you do this, the Central Administration database can grow significantly because of the PowerPivot data history settings.
3-54
Note: All SharePoint farms must have a configuration database and a Central Administration database. Note: PowerPivot tracks all of the information about who is using workbooks in SharePoint 2010 to provide a Workbook Activity chart. This information is stored in the Central Administration database; over time, this can grow to a significant volume.
Additional Reading
For more information about database types and descriptions in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200861&clcid=0x409. For more information about databases used by SharePoint 2010 products, see http://go.microsoft.com/fwlink/?LinkID=201230&clcid=0x409.
3-55
Designing Capacity for Service Application Databases
Key Points
There are several service application databases, the size of which can range from small (less than 1 GB) to extra large (1 terabyte or larger). You must understand which of these databases can require large volumes of storage, and the reasons for the storage requirements, so that you can plan accordingly. The following table provides a brief description of these databases.
Database Usage and Health Data Collection
Size guideline 1 GB more than 1 terabyte
Read/write characteristics Very write-heavy
Description This database stores health monitoring and usage data temporarily, and you can use it for reporting and diagnostics.
3-56
Database Business Data Connectivity Application Registry Service
Size guideline Less than 1 GB Less than 1 GB
Read/write characteristics Very read-heavy
Description This database stores external content types and related objects. This database stores backwardcompatible information for the Office SharePoint Server 2007 Business Data Catalog application programming interface (API). You typically only require this database in upgrade scenarios. This database temporarily stores unaggregated fact data, asset metadata, and queued batch data for the Web Analytics service application. This database stores aggregated standard report tables, fact data aggregated by groups of sites, date and asset metadata, and diagnostics information for the Web Analytics service application. This database stores and manages users and associated information. It also stores information about a user's social network in addition to memberships of distribution lists and sites. This database stores configuration and staging data when synchronizing profile data with directory services such as Active Directory. This database stores social tags and notes that users create, along with their respective URLs. This database stores managed metadata and syndicated content types.
Read-heavy
Web Analytics Staging
1 GB100 GB
Variable
Web Analytics Reporting
1 GB more than 1 terabyte
Variable
User Profile Service Profile
1 GB1 terabyte
Read-heavy
User Profile Service Synchronization
1 GB1 terabyte
Approximately equal
User Profile Service Social Tagging Managed Metadata
Up to 1 terabyte
Read-heavy (approximate 50:1) Read-heavy (approximately 1,000:1)
1 GB100 GB
3-57
Database State
Size guideline 1 GB1 terabyte
Read/write characteristics Variable
Description This database stores temporary state information for InfoPath Forms Service instances, the chart Web Part, and Visio Service instances.
Note: The read/write characteristics of the database should influence your decision about storage in areas such as RAID configuration. Different physical disk types and different RAID configurations can provide different read and write performance. For example, RAID 5 typically has poor write performance when compared with RAID 1.
Question: Which RAID type is typically recommended for transaction log storage of SQL Server databases?
Additional Reading
For more information about database types and descriptions in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200862&clcid=0x409.
3-58
Designing Capacity for Content Databases
Key Points
The following process describes how to estimate the storage that you require for content databases, without considering log files: 1. 2. 3. Calculate the expected number of documents. D represents this value in the formula at the end of this list. Estimate the average size of the documents that you will be storing. S represents this value in the formula at the end of this list. Estimate the number of list items in the environment. L represents this value in the formula at the end of this list. List items can be more difficult to estimate than documents, particularly if there is no existing SharePoint 2010 implementation to base this on. As a general guideline, estimate three times the number of documents. Determine the approximate number of versions. Estimate the average number of versions that any document in a library will have. V represents this value in the formula at the end of this list. The value of V must be at least 1 (for a single, current version).
4.
3-59
5.
Use the following formula to estimate the size of your content databases: Database size = ((D V) S) + (10 KB (L + (V D)))
The value of 10 KB in the formula is a rough estimate of the amount of metadata that SharePoint Server 2010 requires. You should give and calculate all size values in KB to ensure consistency in the calculations.
Note: The features that you are using will determine how you calculate the number of documents. If you are migrating from a current system, it may be easier to extrapolate your current growth rate and usage. If you are creating a new system, review your existing file shares or other repositories and estimate based on that usage rate.
Additional Reading
For more information about storage and SQL Server capacity planning and configuration in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200863&clcid=0x409.
3-60
Designing Capacity for Search Databases and Index Partitions
Key Points
The implementation of search in a SharePoint farm can have significant impact on storage requirements. When a server that hosts the crawl role performs a crawl on content, the following events occur: Search entries are created or updated in an index partition, which is held on crawl and query servers. Metadata about crawled items is added to the Search Service property database. The Search Service crawl database is updated with information about the crawl state.
In addition, the search administration database stores crawl rules. Based on the corpus size, crawl and index entries can require significant storage. The following table describes the three databases that are associated with the Search Service application, with size and read/write characteristics.
3-61
Database Search Service administration database
Size guideline 1 GB100 GB
Read/write characteristics Approximately equal
Description This database hosts the Search Service application configuration, the access control list (ACL), and best bets for the crawl component. Every user and administrative action requires access to this database. This database stores the state of the crawled data and the crawl history. This database stores information that is associated with the crawled data, including properties, history, and crawl queues.
Search Service crawl database Search Service property database
1 GB1 terabyte 1 GB1 terabyte
Read-heavy (ratio 3:1) Write-heavy (ratio 1:2)
Index Partitions
You must also plan for index partition storage on the query servers. Index partitions hold a part of the content index (or the entire content index) against which SharePoint 2010 runs queries to provide search results. You can distribute the index partitions to improve performance. The size of the index and index partitions are determined by the size of the crawled corpus, and they range from 1 GB to 1 terabyte. For general sizing guidelines: The index may occupy 5 to 10 percent of the crawled corpus size. The crawl databases may occupy approximately 5 percent of the crawled corpus size. The property databases may occupy approximately 1.5 percent of the crawled corpus size.
Note: The index and search database sizes can vary greatly depending on the type of files that are crawled and the file crawl limit. Note: The index servers build small parts of the index before forwarding these parts to the query servers. The index servers require a small amount of local storage for this process.
3-62
Additional Reading
For more information about database types and descriptions in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200864&clcid=0x409. For more information about storage and SQL Server capacity planning and configuration, see http://go.microsoft.com/fwlink/?LinkID=201267&clcid=0x409.
3-63
Planning for Remote BLOB Storage for SharePoint 2010
Key Points
BLOBs are data elements that have either of the following characteristics: Unstructured data with no schema (such as a piece of encrypted data). A large amount of binary data (many megabytes or gigabytes) that has a very simple schema, such as image files, documents, streaming video, or sound clips.
By default, SharePoint 2010 stores BLOBs in the content databases. This can result in a dramatic size increase for the content database and associated storage requirements. SharePoint 2010 with SQL Server 2008 R2 supports remote BLOB storage. With a remote BLOB storage provider, remote BLOB storage can store BLOB data outside the content database on separate storage. The SQL Server 2008 R2 Feature Pack includes a RBS FILESTREAM provider called the local FILESTREAM provider. This provider is able to store BLOBs on separate, local disks.
3-64
SQL Server 2008 Enterprise and SQL Server 2008 R2 Enterprise also offer remote BLOB storage without FILESTREAM that can use NAS or DAS storage, and additional third-party remote BLOB storage options may be available.
Note: It is important to identify that SharePoint 2010 (rather than SQL Server 2008) supports the use of the remote BLOB storage provider that you want to use.
Additional Reading
For more information about planning for remote BLOB storage in SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200865&clcid=0x409.
3-65
Lab: Planning for Performance and Capacity
Exercise 1: Creating a Performance Plan

Scenario
Having completed the logical architecture planning and service application planning activities, you must now identify the number of WFE servers that are required for the Contoso, Ltd. SharePoint 2010 production farm. There is additional planning information available in the supplied documents. Use these documents to produce your performance plan. The main tasks for this exercise are as follows: 1. 2. Read the supporting information. Complete the Performance worksheet in the Performance and Capacity Planning Worksheet.xlsx file.
3-66

1. 2. 3. 4. 5. Read the lab scenario. Log on to 10231A-NYC-DC1-03 as CONTOSO\Ed with the password Pa$$w0rd. In the E:\Labfiles\Lab03\Starter folder, read the Performance and Capacity Requirements.docx file. In the E:\Labfiles\Lab03\Starter folder, read the SharePoint 2010 Capacity Planning Excerpt.docx file. In the E:\Labfiles\Lab03\Starter folder, read the information under Workload in the Right-Sizing SharePoint Server 2010 Deployments section of the SPServer2010CapacitySizingOverview.docx file.
Task 2: Complete the Performance worksheet in the Performance and

Capacity Planning Worksheet.xlsx file
In the E:\Labfiles\Lab03\Starter\Performance and Capacity Planning Worksheet.xlsx file, complete the details on the Performance worksheet to establish the number of WFE servers that you require.
Exercise 2: Creating a Capacity Plan

Scenario
You now need to plan the storage requirements for Contoso, Ltd. There is additional planning information available in the supplied documents. Use these documents to produce your capacity plan. The main tasks for this exercise are as follows: 1. 2. Read the supporting information. Complete the Capacity worksheet in the Performance and Capacity Planning Worksheet.xlsx file.

1. Review the lab scenario.
3-67
2.
In the E:\Labfiles\Lab03\Starter\ folder, read the information under Dataset in the Right-Sizing SharePoint Server 2010 Deployments section of the SPServer2010CapacitySizingOverview.docx file.
Task 2: Complete the Capacity worksheet in the Performance and

Capacity Planning Worksheet.xlsx file
In the Performance and Capacity Planning Worksheet.xlsx file, in the Capacity worksheet, complete the details to establish the database storage requirements.
3-68
Review Questions
1. 2. What are the two tools that you can use to measure the performance of a WFE server in a SharePoint test farm? When you calculate content database size, you must estimate the number of stored documents. Should you estimate the number of versions of documents that you will keep?
3. What is the maximum recommended size for a content database? 4. 5. What is the BLOB cache? Is the SharePoint search index stored in a database?
3-69
Best Practices Related to Performance and Capacity Planning

Supplement or modify the following best practices for your own work situations: Understand your user requirements. Establish your organizations performance and capacity requirements. Deploy a test farm for performance testing on similar hardware to your production environment. Estimate the content database size through calculation or from existing storage requirements. Limit database size to 200 GB. Limit site collection size to 100 GB. Plan storage for transaction logs. Plan storage for service application databases. Enable BLOB caching for digital assets.
Designing a Physical Architecture
4-1
Module 4
Contents:
Lesson 1: Designing Physical Components for SharePoint Deployments 4-4 Lesson 2: Designing Supporting Components for SharePoint Deployments 4-20 Lesson 3: SharePoint Farm Topologies Lesson 4: Mapping a Logical Architecture Design to a Physical Architecture Design Lab: Designing a Physical Architecture 4-37 4-47 4-27
4-2
Module Overview
When you design a Microsoft SharePoint 2010 deployment, you must carefully consider the hardware and farm topology requirements. Your choices of server hardware and the number of servers that you specify for the farm can have a significant impact on how the farm meets user requirements, how users perceive the SharePoint solution, and how long before the farm requires additional hardware. This module describes the factors that you should consider when you design the physical architecture of a SharePoint 2010 deployment. The physical architecture refers to the server design, farm topology, and supporting elementssuch as network infrastructurefor your deployment. This physical architecture underpins the operations of your SharePoint 2010 environment, so it is essential that your physical design fully meets the operational requirements.
4-3
Objectives
After completing this module, you will be able to: Describe the physical design requirements for SharePoint 2010. Describe the supporting requirements for a successful SharePoint 2010 physical design. Identify SharePoint farm topologies. Map a logical architecture design to a physical architecture design.
4-4
Lesson 1
Designing Physical Components for SharePoint Deployments
Before committing to specific numbers of servers, you must understand the basic hardware and software requirements. In addition, you should also consider options such as server virtualization and disk storage choices because these choices will have a fundamental effect on management options and the planning of high availability. You should also note that there may be nonfunctional, or implicit, requirements that the organization expects from the SharePoint deployment. Identifying these nonfunctional requirements is an important step toward establishing the best design and gaining user adoption.
Objectives
After completing the lesson, you will be able to: Identify minimum hardware requirements. Identify software requirements.
4-5
Identify server virtualization options. Identify storage choices. Identify database configuration options. Map functional and nonfunctional requirements to your design.
4-6
Hardware Requirements
Key Points
The following table shows the hardware requirements for Web Front End (WFE) servers, application servers, and single-server installations.
Component Processor (CPU) Memory (RAM) Minimum requirement 64 bit, four cores. 4 gigabytes (GB) for developer or evaluation use. 8 GB for production use (single-server or multiple-server farm). Hard disk 80 GB for the system drive. In production use, you will require additional disk space for daily operations. You should maintain twice as much free disk space as RAM.
In multiple-server farms, database servers should use the minimum requirements that are shown in the following table.
4-7
Component Processor (CPU)
Minimum requirement 64 bit, four cores for small deployments (see Standard Farm Topologies later in this module). 64 bit, eight cores for medium deployments (see Standard Farm Topologies later in this module).
Memory (RAM)
8 GB for small deployments. 16 GB for medium deployments.
Hard disk
80 GB for the system drive. Additional database storage, based on content requirements and farm configuration.
Note: The minimum requirement values for a database server are higher than the minimum requirements for installing Microsoft SQL Server due to the significant load on the database servers in a SharePoint farm.
Additional Reading
For more information about hardware and software requirements for SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200868&clcid=0x409.
4-8
Software Requirements
Key Points
WFE and application servers in a farm require the following software: Windows Server 2008 Standard, Enterprise, Datacenter, or Web Server (64bit edition) with Service Pack 2 (SP2). Alternatively, Windows Server 2008 R2 Standard, Enterprise, Datacenter, or Web Server. Web server (Internet Information Services (IIS)) role. Application server role. Microsoft .NET Framework version 3.5 SP1. KB979917 - QFE for Sharepoint issues - Perf Counter fix & User Impersonation. Microsoft Sync Framework v1.0 (x64). Microsoft Filter Pack 2.0. Microsoft Chart Controls for Microsoft .NET Framework 3.5. Windows PowerShell 2.0.
4-9
SQL Server 2008 Native Client. SQL Server 2008 Analysis Services ADOMD.NET. ADO.NET Data Services Update for .NET Framework 3.5 SP1. Windows Identity Foundation (WIF).
Note: An update to support token authentication without transport security or message encryption in Windows Communication Foundation (WCF) is required for the .NET Framework 3.5 SP1 in Windows Server 2008 SP2 or Windows Server 2008 R2 before you run Setup.
Database servers require any 64-bit version of Windows Server 2008 (or Windows Server 2008 R2) with one of the following databases installed: SQL Server 2008 R2. The 64-bit edition of SQL Server 2008 with SP1 and cumulative update (CU) 2 or CU5.
Note: CU3 and CU4 are not recommended; instead, use CU2 or CU5.
The 64-bit edition of SQL Server 2005 with SP3 and CU3.
Additional Reading
For more information about software requirements for SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200869&clcid=0x409.
4-10
Virtualization Considerations
Key Points
Server virtualization with Hyper-V on Windows Server 2008 is becoming commonplace in many organizations. Companies use virtualization to improve server utilization and management, add flexibility to datacenters, or decrease the costs that are associated with running multiple physical servers. If you take the correct planning and sizing steps prior to deployment, then you can virtualize some or all of the servers in a SharePoint farm successfully.
WFE and Application Servers

WFE and application servers are both good candidates for virtualization. You should use performance and capacity planning guidelines to plan the number of servers that you require. You should then consider which of these servers you want to virtualize. If you plan to virtualize several, or perhaps all, of the WFE and application servers, you may require additional virtual servers to achieve the same performance as the same number of physical servers would achieve. This requirement results from the performance overhead of the virtualization platform. Using Windows Server 2008
4-11
R2 Hyper-V, you can achieve near parity to physical performance with the correct planning.
Database Servers
Virtualizing database servers running SQL Server is a difficult design decision, because the performance overhead of the virtualization platform can affect the entire solution. However, SharePoint 2010 fully supports virtualized database servers. You can always add more virtual database servers to improve performance if required. In addition, you should allocate the same level of hardware resources, such as processor cores and memory, to the virtual server as you would to a physical server.
High Availability
Your virtualization platform may introduce additional high-availability options. Some virtualization software, including Hyper-V, can make hosted virtual machines highly available when you configure a failover cluster for the virtualization servers. In these circumstances, individual virtual machines, such as WFE or application servers, can fail over from one virtual host server to another.
Additional Reading
For more information about virtualization for SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200870&clcid=0x409. For more information about SQL Server 2008 virtualization, see http://go.microsoft.com/fwlink/?LinkID=201232&clcid=0x409. For more information about how to plan virtual architectures by using SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=201233&clcid=0x409. For more information about capacity management and high availability in a virtual environment hosting SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=201234&clcid=0x409.
4-12
Storage Options
Key Points
When you plan for content storage on SharePoint 2010, you must choose a suitable storage architecture. SharePoint content storage has a significant dependency on the underlying database; therefore, database and SQL Server requirements will drive your storage choices.
Storage Architecture
The following storage architectures are suitable for SharePoint 2010: Direct attached storage (DAS), where hard disks are attached directly to the computer running SQL Server. Storage area network (SAN), which uses a network infrastructure to connect the computer running SQL Server to the separate disk storage volumes. Network attached storage (NAS) devices may be suitable, under certain circumstances, such as for remote binary large object (BLOB) storage. However, this support is subject to precise NAS specifications.
4-13
Note: Content databases with remote BLOB storage are the only configuration in which SharePoint 2010 supports NAS storage. Any network storage architecture must respond to a ping within one millisecond and must return the first byte of data within 20 milliseconds.
DAS is typically a significantly cheaper option than SAN storage. However, DAS usually offers fewer management capabilities and fewer options for high-availability configurations. SAN storage can support failover clustering in SQL Server and may provide additional disaster recovery options, such as SAN mirroring.
Note: In general, you should choose a DAS architecture if a shared storage platform cannot guarantee a response time of 20 milliseconds or less and sufficient capacity for average and peak I/O operations per second (IOps).
RAID
SharePoint 2010 works well with redundant array of independent disk (RAID)based storage, which offers improved performance, additional fault tolerance, or both, depending on the RAID option that you choose. The following table describes the most common RAID types.
RAID configuration RAID 0 Description Offers improved performance by striping data across disks in the array. Not fault tolerant. Duplicates (mirrors) data onto a second disk in the array. Fault tolerant, but no significant performance improvement. Uses three or more disks to provide fault-tolerant storage with less wasted space than RAID 1. RAID 5 typically offers good read I/O characteristics; however, disk write performance is typically slower than normal, due to the fault-tolerance requirement. Uses a combination of RAID 1 to provide fault tolerance and RAID 0 to provide a performance improvement. More expensive than RAID 1 or RAID 5, but ensures optimum write performance.
RAID 1
RAID 5
RAID 10
Disk Types
Different storage architectures use a range of disk types. These disk types include: Serial Advanced Technology Attachment (SATA).
4-14
Small Computer System Interface (SCSI). Serial Attached SCSI (SAS). Solid State Drive (SSD) or Flash Disk.
These disk types have varying performance, capacity, and cost characteristics that you must take into consideration when you design your SQL Server storage architecture. Question: What is the minimum number of physical disks that you require to implement RAID 10?
Additional Reading
For more information about how to design storage architecture based on capacity and I/O requirements, see http://go.microsoft.com/fwlink/?LinkID=200871&clcid=0x409.
4-15
Database Configuration Options
Key Points
SharePoint content, services, and configuration databases are stored on computers running SQL Server; therefore, there are options for database configuration that you must consider in your planning. The database recovery model controls transaction log behavior in SQL Server databases. There are three database recovery models available: Simple recovery. This model reuses log file space. This occurs after transactions have been committed to the database but before a database backup occurs. This model reduces the amount of disk space that is required between consecutive backup operations. However, if a corruption or disk failure occurs, you can only restore the database to the last backup. Full database. This model never reuses log file space. Instead, it increases the size of the log file (and the storage requirement) when it performs new transactions. If a database problem occurs, it is possible to restore the database up to the last transaction, if the transaction log file is intact. For this reason, it is best practice to store the database and log files on separate disks.
4-16
Bulk-logged database. This model is very similar to the full model; the exception is that bulk operations on the database are only partially reproduced in the log file, so these bulk operations cannot be performed as a recovery operation. This model is useful for short periods during large bulk operations, but it is not recommended for SharePoint databases.
The following table shows the default database recovery model for databases in a SharePoint farm.
Database Farm configuration database Central administration content database Content databases Usage and Health Data Collection database Business Data Connectivity database Application Registry database Secure Store database State database Web Analytics Staging database Web Analytics Reporting database Search service application administration database Search service application Crawl database Search service application Property database User Profile service application profile database User Profile service application synchronization database User Profile service application social tagging database Managed metadata database Default database recovery model Full Full Full Simple Full Full Full Full Full Full Simple Simple Simple Simple Simple Simple Full
4-17
Database Word Automation Services database PerformancePoint service application database PowerPivot application database
Default database recovery model Full Full Full
Other considerations may include the placement of the tempdb database in the SQL Server file system. Testing and customer data show that insufficient disk I/O for the tempdb database can significantly impede SharePoint Server 2010 farm performance. To avoid this issue, allocate dedicated disks for the tempdb database. For best performance, place the tempdb database on a RAID 10 array.
Note: In some organizations, a dedicated team of database administrators (DBAs) will manage the computers running SQL Server. In these environments, you may need to discuss the requirements for the SharePoint databases with the DBA. This discussion will enable the DBA to understand the function and purpose of the database so that he or she can select the relevant management options.
Additional Reading
For an overview of recovery models, see http://go.microsoft.com/fwlink/?LinkID=200872&clcid=0x409. For more information about how to choose the recovery model for a database, see http://go.microsoft.com/fwlink/?LinkID=201235&clcid=0x409. For more information about how to configure SQL Server databases for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=201236&clcid=0x409.
4-18
Functional and Nonfunctional Design Mapping
Key Points
In any deployment project, there will be both functional and nonfunctional requirements. Functional requirements are those that the organization or end-user community explicitly states or requests. It is important that your solution design takes account of these functional requirements because these typically drive the solution. These requirements may help you to calculate the minimum number of servers that you require, based on user load and feature requirements. They may also help you to calculate the number of application servers that you require, because additional application service features are necessary.
4-19
This table shows examples of functional design mappings.

Requirement Team collaboration Browser-based slideshows Company forms Feature Collaboration sites Office Web Apps InfoPath Forms Design impact Number of WFE servers Number of application servers Number of WFE and application servers
In addition to functional requirements, you must also plan for nonfunctional requirements. Nonfunctional requirements may be existing policies that you must use, such as a security policy that details authentication methods. These nonfunctional requirements may also be essential elements that the end-user community does not directly specify, such as the auditing of documents, which affect storage requirements. This table shows examples of nonfunctional design mappings.
Requirement Security Design impact Supported authentication methods and user stores
Governance
Data life cycle impact on storage sizing
Business continuity
Database size, backup/restore, and high availability
Capacity
Storage sizing and media
4-20
Lesson 2
Designing Supporting Components for SharePoint Deployments
In addition to designing your SharePoint deployment, you must also understand the requirements of the supporting network and services. You should consider supporting requirements such as Domain Name System (DNS) or the Active Directory directory service because the service behavior and requirements may affect your farm topology or server placement within the network.
Objectives
After completing this lesson, you will be able to: List the requirements for Active Directory and DNS elements to support a SharePoint farm. Identify design considerations for IIS. Identify design requirements for SQL Server.
4-21
Requirements for Active Directory and DNS
Key Points
For SharePoint multiple-server farm deployments, you will require an Active Directory domain infrastructure to support the authentication of service application accounts. In addition, Active Directory is the most common store for user accounts to control access to SharePoint content. Although this is a common configuration for most internal corporate networks, you should consider how this requirement affects extranet and Internet-facing farm deployments. You may want to consider using read-only domain controllers (RODCs) to assist in such environments. You should also place domain controllers in the same Active Directory site as the SharePoint farm servers for best performance. Configuring domain controllers in the same Active Directory site as global catalog (GC) servers also ensures optimum performance for GC lookups, such as using the People Picker. In your DNS environment, you should ensure that you have provisioned any fully qualified domain names (FQDN) for the WFE servers into the relevant DNS zones. These FQDN entries may be required to enable Web application name resolution such as alternate access mappings. Your SharePoint servers may also require
4-22
Internet name resolution, for example, if you want to display Internet-based feeds on SharePoint Web pages.
4-23
Design Considerations for IIS
Key Points
SharePoint 2010 uses the IIS component of Windows Server 2008 to receive and respond to Web browser requests. You perform most SharePoint 2010 configuration tasks in SharePoint Central Administration, but you should be aware that you may have to perform some Web service management tasks outside SharePoint 2010. You may require encrypted Web traffic, for example, to protect user access over the Internet. In this scenario, you can use Secure Sockets Layer (SSL) to encrypt traffic and establish a secure connection between the client and the WFE server. To enable SSL, you require a properly configured Web server certificate. You perform the installation of the certificate to the appropriate Web site in IIS. You may also require additional host headers for a Web application, such as when you configure alternate access mappings to enable multiple URLs for a single content source. In this scenario, you must configure the host header in the IIS Manager console.
4-24
You configure certain settings for the Web application, such as BLOB cache settings, in the Web.config file. This file is stored in the directory for the Web application on the WFE server(s). If you have multiple WFE servers in the farm that host the same Web applications, you must also consider how you duplicate and back up these settings on the necessary WFE server.
4-25
Design Requirements for SQL Server
Key Points
Most small and medium-size SharePoint farm deployments use a single database server as a starting point. Only as transaction levels increase will administrators consider scaling out to larger farm topologies. There are several reasons to consider multiple database servers to support a SharePoint 2010 farm: You can use additional computers running SQL Server to distribute I/O operations and database access loads for heavy workloads. This configuration can be for a service application, such as search, or to separate heavy collaboration-based site collections from other content. You can use a second computer running SQL Server to implement a form of database high availability that is known as database mirroring or log shipping. Database mirroring copies transaction log data from the computer running SQL Server that holds the live copy of the database to a standby server with a second copy of that database. If the live database fails, the standby server can take over database operations in a process known as failover. Database
4-26
mirroring requires a copy of the database and log files on both the live and standby servers. Log shipping is similar to database mirroring, but does not guarantee transactional consistency, and cannot perform automatic failover. You can use additional computers running SQL Server to implement a form of server high availability known as failover clustering. Failover clusters require shared storage, such as a SAN, to share the database volumes and log files among multiple instances of SQL Server running on different cluster nodes. This arrangement offers additional scalability beyond database mirroring. Based on licensing requirements, the following two failover cluster configurations are available: You can use SQL Server Standard and Windows Server Enterprise on each cluster node to create a two-node failover cluster. You can use SQL Server Enterprise and Windows Server Enterprise on each cluster node to create a failover cluster that can scale up to 16 nodes.
Note: High availability options in themselves do not spread load between cluster nodes and therefore do not improve performance in their own right.
Question: How can you provide additional computers running SQL Server to accommodate heavy database workloads and provide high availability?
Additional Reading
For more information about high availability with SQL Server 2008, see http://go.microsoft.com/fwlink/?LinkID=200873&clcid=0x409.
4-27
Lesson 3
SharePoint Farm Topologies
This lesson reviews the options for a SharePoint farm topology. The flexibility of the SharePoint topology enables solution architects to tailor each farm deployment to the specific sizing and performance requirements of their organization. Using SharePoint 2010, you may choose to deploy a single farm to service all requirements. Alternatively, you may choose to deploy multiple farms based on separating authoring and publishing processes or multiple farms for a geographically distributed user base. In addition, multiple farms can share some service applications, or a single farm can provide content requirements for several different organizations simultaneously.
Objectives
After completing this lesson, you will be able to: Identify suitable topologies for single farms. Explain options for multiple farm topologies and cross-farm services.
4-28
Identify topologies for multiple farms to support content publishing. Describe the support for multi-tenancy in SharePoint 2010.
4-29
Single Farm Topologies
Key Points
Farm topology is extremely flexible in SharePoint 2010. For example, you can add servers to a farm (scale out) to share existing services with the current farm servers. You can also dedicate specific servers to running specific service applications, such as search or Excel Services, or dedicate servers as WFE servers. There are three categories of farm topologies: Small farms. These farms typically have between two and approximately five servers, and they can have two or three tiers. In a small, two-tier farm, the WFE server(s) also run service application components such as search query, search crawl, or Microsoft InfoPath forms. A small farm can serve between 10,000 to 20,000 users depending on usage and service requirements. Medium farms. These farms have between approximately five and 10 servers, separated into three tiers. In medium farms, service applications are often spread out across a number of application servers, with dedicated search servers. A medium farm can manage up to 40 million items. You can extend a medium farm by having more than one database server, with the search databases separated from other SharePoint databases.
4-30
Large farms. These farms typically start at approximately 10 servers and scale out. The recommendation for scaling out a large farm is to group services or databases with similar performance characteristics onto dedicated servers and then scale out the servers as a group.
Note: Server groups are only a design conceptthere is no such management object in a SharePoint 2010 farm.
Question: In a medium farm with a single database server, you plan to add an additional database server for performance reasons. Which service application databases would you move to the new database server first?
Additional Reading
For more information about topologies for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=167089.
4-31
Multiple Farm Topologies and Cross-Farm Services
Key Points
In SharePoint 2010, you can share some service applications among different farms in the same organization. This enables you to unify or standardize certain service applicationrelated elements. For example, an organization may have two separate SharePoint farms for different departments or geographic regions. In such an environment, you can create a dedicated search farm that can crawl content fromand provide search results to both farms simultaneously. Scaling out in this way to multiple farms also provides performance opportunities. For example, you can use a dedicated search farm to scale for indexes that include more than 40 million items. Cross-farm services are applications that can be shared independently with other farms. Some service applications can be shared out to another farm and simultaneously consumed from services running in other farms. For example, an organization may have two farms that both use the Managed Metadata Service to define metadata. Farm A can use the local Managed Metadata Service and consume the Managed Metadata Service of Farm B, which makes both sets of metadata
4-32
available. You can repeat this configuration on Farm B so that both farms can share metadata definitions. By necessity, topologies for multiple farms increase the number of physical servers that you require. However, farms that are dedicated to the provision of service applications may not require any WFE servers. Due to the increased number of servers required, multiple farm topologies are a good candidate for virtualization.
4-33
Multiple Farms for Content Publishing
Key Points
Many organizations want to ensure a controlled distribution of content through an authoring and review process before they make the content live in a production environment. Organizations may consider deploying multiple farms to hold content at different stages of this process. An authoring farm enables content authors to make changes to content, and such farms are often maintained on the internal network. Some parts of the review process may take place while the content is only held here, and other reviews may occur after the content moves to a staging environment. Organizations can use a staging farm to hold a final draft of items before they move them to a production environment. At the staging farm, final reviews for content suitability, style, and layout can occur before they publish the item into general circulation. A production farm enables readers to browse final content without any crossover with draft and authoring processes. You should only move content to the production farm after all reviews are complete. You can place production farms in a perimeter network for access from the Internet.
4-34
You can move content from one farm to the next in the process by using content deployment to assist in automating elements of the process.
Note: The use of different server farms for authoring or staging purposes is typically only suitable for publishing content, not collaboration content.
Some organizations will use additional farm environments, such as a development farm and a testing farm. Organizations often use these farm environments when additional coding requirements exist, such as in-house or third-party Web Parts.
Additional Reading
For more information about the topology of design content deployment, see http://go.microsoft.com/fwlink/?LinkID=200874&clcid=0x409.
4-35
Multi-Tenancy Environments
Key Points
SharePoint 2010 has significantly improved options for hosting providers. Improvements in logical architecture enable you to implement farm deployments that use a multi-tenancy model. Multi-tenancy means that different companies can share a single farm environment. This arrangement suits large organizations with subsidiary companies that have specific requirements for SharePoint 2010. The parent company can provision and manage a large farm with segregated content areas for the subsidiaries; the parent company and the subsidiaries can combine investment in hardware and licensing and share the benefits. The multi-tenancy model also suits SharePoint hosting providers as part of a commercial hosting model, where customer companies pay for SharePoint storage and service provisioning. In both cases, it is important to follow server guidelines and topology options to provide sufficient levels of performance for end users.
4-36
Additional Reading
For more information about SharePoint 2010 for hosters, see http://go.microsoft.com/fwlink/?LinkId=190783.
4-37
Lesson 4
Mapping a Logical Architecture Design to a Physical Architecture Design
There is a strong link between the logical architecture of SharePoint 2010 and the physical architecture of SharePoint 2010. Some of the design choices that you make for the logical architecture will have a direct impact on the physical architecture, such as the number of databases that you require or the number of servers that you need in the farm. This lesson maps some of the links between logical and physical architectures, and discusses supporting requirements for your farm topology.
Objectives
After completing this lesson, you will be able to: Identify existing management requirements, and the impact on SharePoint. Identify links between logical and physical architectures in SharePoint.
4-38
Describe additional SharePoint topology requirements. Document the physical design.
4-39
Physical Design in a Business Context
Key Points
Typically, your SharePoint farm solution will not exist in isolation. There will usually be an existing network infrastructure with additional network services in place, which your SharePoint farm will supplement. This means that there will be existing elements that you must account for in your design. The following list contains some examples of existing support requirements or policies: There may be existing security requirements or policies that govern how servers can transmit data, or there may be configuration requirements for Web servers in perimeter networks. There may be existing authentication requirements that the SharePoint solution must also meet, such as two-factor authentication devices. There may be firewall policies that can restrict placement of domain controllers in the perimeter network or prevent logon traffic from successfully passing.
4-40
When you calculate network usage and bandwidth requirements, you must take account of other network usage on shared network segments. You must include this usage in your calculations and your performance testing. Your organization may require that SQL Server DBAs administer the SharePoint database servers instead of SharePoint administrators.
4-41
Mapping Logical Architecture Design to Physical Specifications
Key Points
After you have established a logical architecture design, you can decide on the physical farm, server specifications, and number of servers. Many of the logical architecture elements will have an impact on the physical specifications. The following table lists some examples of relationships between logical design and physical requirements.
4-42
Logical design requirements Size of repository
Impact on physical specifications For large content collections (corpus over 40 million items) or multiple-farm scenarios, this repository may require a dedicated search farm. The number of Web applications, and the number of users who connect to them, will have an impact on the number of WFE servers that you require. More WFE servers can offer dedicated hosting of individual Web applications. As content demand increases, you require additional databases to store content beyond 200 GB. Further demand may result in splitting service application databases, such as search, onto additional servers. You may also need to review the disk storage type (RAID configuration or SAS/SATA) Microsoft Office Web Apps place more demand on network bandwidth, in addition to WFE and application servers. Host header and alternate access mapping use requires additional DNS record configuration. You may need to change internal DNS or Internet DNS or both. Digital asset management requires additional content storage considerations, either for database storage or for remote BLOB storage (RBS). RBS requires compatible storage options. In addition, you should consider configuration of BLOB caching on WFE servers.
Number of Web applications
Quantity of content
Presence of Microsoft Office Web Apps
Mappings for host headers and alternate access
Management of digital assets
4-43
Additional Topology Considerations
Key Points
In addition to designing the number of farms that you require and sizing the farm(s), you must consider farm placement.
Network
If users who will access the farm are solely on the internal network, you can place the farm in the internal network, and access requirements are satisfied. If the farm must be accessible from the Internetto corporate users, business partners in an extranet scenario, or publiclythere are a number of options for deployment of the farm and Active Directory. The following table describes the server placement options and corresponding considerations.
4-44
Farm placement Internal network
Active Directory placement Internal network
Considerations HTTP (or HTTPS) traffic must pass from the Internet to the WFE servers in the internal network. For improved security, use an application-layer firewall, such as Microsoft Threat Management Gateway. Authentication traffic must pass back from the WFE servers to the domain controllers in the internal network. Requires careful configuration of firewall to securely pass both Active Directory traffic between domain controllers and traffic from WFE and application servers back to computers running SQL Server.
Perimeter network
Internal network
Split WFE and application servers in the perimeter network, computers running SQL Server in the internal network Perimeter network
Split domain controllers for internal domain in both internal and perimeter network Perimeter network (separate forest)
This configuration provides Active Directory in the perimeter network, but as a separate forest. Typically, this prevents single sign-on (SSO) for corporate users, because a separate account is required for authentication in the perimeter forest (although you can establish a trust relationship).
Note: You should choose an Active Directory and farm placement configuration that best meets your organizations security and authentication requirements.
Antivirus
You must also consider how to protect SharePoint content against viruses and malware. You should consider integration with your corporate antivirus strategy, or you may require dedicated SharePoint antivirus software if your current antivirus software does not provide integration with SharePoint 2010.
High Availability
You must also consider high-availability requirementsadditional servers may be necessary to support extended uptime requirements. For high-availability requirements, you must consider the three farm tiers separately:
4-45
To implement high availability for WFE servers, you require at least two WFE servers that host the same Web application, with load balancing. The load balancing element may be a hardware load balancer or the network load balancing (NLB) feature in Windows Server 2008. NLB is available in Windows Server 2008 Web, Standard, Enterprise, and Datacenter editions. To implement high availability for service applications, you can implement multiple application servers that host the same services. To implement high availability for databases, you require at least two computers running SQL Server. You can configure these for database mirroring (which requires duplicate storage), or you can configure them as part of a SQL Server failover cluster (which requires shared storage).
Note: You may also be able to achieve high availability when you virtualize SharePoint servers. Depending on the virtualization platform requirements, a single virtual WFE, application, or database server can be highly available across multiple virtual host servers.
Question: You decide to implement two computers running SQL Server in a mirrored configuration for high availability. Will this configuration also improve performance? Explain your reasons for your answer.
Additional Reading
For more information about how to plan for availability in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200875&clcid=0x409.
4-46
Documenting the Physical Design
Key Points
After you have designed your physical server requirements and farm topology, it is important to document your design and record all of the required elements ready for deployment. This design document will also help when you deploy the farm, because you can identify dependencies, create a work sequence to follow, and ensure that you do not forget any requirements during deployment. You should create a worksheet to describe the server requirements, including the server hardware configuration, network settings, domain membership, and which servers will host service applications in the farm. After you create the server planning worksheet, you can create a network diagram of your farm topology. This diagram can detail: The number and type of servers. Additional requirements, such as domain controllers or firewalls. The type of storage that servers will use, such as DAS or SAN.
4-47
Lab: Designing a Physical Architecture
Exercise 1: Planning the Physical Architecture

Scenario
Contoso Pharmaceuticals Research is requesting its own SharePoint farm. However, you have logically separated its Web and service applications, so you should now identify the most cost-effective solution that satisfies the Contoso Ltd requirements. The information that your team requires is detailed in the supplied documents. Use these documents to produce your physical SharePoint design. The main tasks for this exercise are as follows: 1. 2. 3. Read the supporting information. Complete the Physical Architecture Planning worksheet. Complete the Physical Architecture diagram.
4-48

1. 2. 3. Read the lab scenario. Log on to 10231A-NYC-DC1-04 as CONTOSO\Ed with the password Pa$$w0rd. In the E:\Labfiles\Lab04\Starter folder, review the Physical Architecture Requirements.docx file.
Task 2: Complete the Physical Architecture Planning worksheet

In the E:\Labfiles\Lab04\Starter folder, complete the details for all production, staging, and test servers in the Physical Architecture Planning Worksheet.xlsx file.
Task 3: Complete the Physical Architecture diagram

In the E:\Labfiles\Lab04\Starter folder, complete the farm design in the Physical Architecture Diagram.vsd file.
Exercise 2: Troubleshooting a Name Resolution Problem

Scenario
Using the completed design, your team configured SharePoint in the lab environment. You can access the intranet site by navigating to http://nyc-dc1, but not http://intranet.contoso.com. You must resolve this problem and ensure that it does not recur in the production environment. The main tasks for this exercise are as follows: 1. 2. Attempt to access the Contoso, Ltd intranet by using two different URLs. Resolve the name resolution problem.
Task 1: Attempt to access the Contoso, Ltd intranet by using two

different URLs
1. In Windows Internet Explorer, go to http://nyc-dc1. You should be able to view the Contoso, Ltd home page.
4-49
2.
In Internet Explorer, go to http://intranet.contoso.com. You will receive an error page.
Task 2: Resolve the name resolution problem

1. Use SharePoint Central Administration to create an alternate access mapping for the SharePoint-80 Web application with the following settings: 2. 3. 4. Zone: Intranet Address: http://intranet.contoso.com
Add a new host (A) record for intranet.contoso.com with the IP address 10.10.10.1. Add intranet.contoso.com as a host header for the SharePoint-80 Web site in IIS. In Internet Explorer, go to http://intranet.contoso.com. You should be able to view the Contoso, Ltd home page.
4-50
Review Questions
1. 2. 3. 4. On which editions of Windows Server 2008 can you install SharePoint 2010? Which SQL Server database recovery model is not suitable for SharePoint 2010 databases? What is the maximum recommended size for a content database that contains multiple site collections? Which tool must you use to add SSL certificates to SharePoint Web applications?
4-51
Best Practices Related to Designing a SharePoint 2010 Physical Architecture

Supplement or modify the following best practices for your own work situations: Perform logical architecture design before physical architecture design. Consider existing network and security policies. If you are making content accessible to the Internet, carefully consider server placement and protecting the connection by using an application-layer gateway device. Carefully size site collections so that they do not exceed database storage recommendations.
Designing a Security Plan
5-1
Module 5
Contents:
Lesson 1: Designing Security for SharePoint 2010 Lesson 2: Planning for Service Accounts Lesson 3: Planning Security for Users and Groups Lesson 4: Planning for SSL Lab: Designing a Security Plan 5-3 5-8 5-18 5-32 5-36
5-2
Module Overview
This module describes the key elements that you must consider when you design a security plan for Microsoft SharePoint 2010. A robust security plan is crucial to protect your SharePoint 2010 structure and the content that you store in it. You must plan how you will secure the service accounts that support SharePoint services, control access to SharePoint sites, and secure the traffic that passes between client and server.
Objectives
After completing this module, you will be able to: Describe the security architecture in SharePoint 2010 and the importance of the principle of least privilege. Identify and plan security for core service accounts. Describe the considerations for implementing security for users and groups. Explain the options for implementing Secure Sockets Layer (SSL) in SharePoint 2010.
5-3
Lesson 1
Designing Security for SharePoint 2010
To design effective security for your SharePoint 2010 infrastructure, you must balance the need to reduce the risk of a security failure with the need to make SharePoint content and features accessible to users who need them. You must ensure that your security model provides the appropriate level of access for those who require it. You must also prevent inappropriate access. The principle of least privilege is the cornerstone of an effective security plan. This principle states that you should give users the permissions that they require to perform their job tasks and no more. It is important that you can apply the concepts of least privilege appropriately in SharePoint 2010.
Objectives
After completing this lesson, you will be able to: Explain the principle of least privilege. Describe the security architecture in SharePoint 2010.
5-4
What Is the Principle of Least Privilege?
Key Points
The principle of least privilege is the strategy of assigning a user the fewest possible permissions that still allow the user to perform all required actions. The principle applies regardless of how you grant the permissionswhether through membership of groups or roles, the effects of policies, or direct assignment to the user account. When you design a security plan for SharePoint 2010, you must apply this principle to standard user accounts, groups, service accounts, and administrator accounts. Designing for least privilege may incur some extra administrative effort; for example, you may decide to create a new service account so that you can control permissions for a particular service application. However, designing for least privilege will help you to ensure that your SharePoint deployment remains secure. You should apply the principle of least privilege to all of the elements in a SharePoint 2010 infrastructure. The following list describes some of the key areas that you should consider:
5-5
Installation privileges. SharePoint 2010 has its own account that you use to run the initial setup process and the SharePoint Products Configuration Wizard. You should not use your own account or a generic administrative account. This specific SharePoint account must be a local administrator but should not be a domain administrator. Administrator privileges. Administrative privileges should only be granted if these privileges are necessary. Never grant them where they are not specifically required. This applies to domain administrators, local administrators, site collection administrators, and Internet Information Services (IIS) administrators. Services. Each service relies on a service account. Some services require a separate account that is dedicated to their specific role. You can create a separate account for a particular service to provide isolation for that service. For example, you can create a separate account for the Search Crawl Service. This service is often configured to use the service account for the SharePoint farm, which grants more privileges than are required. This creates a security risk by exposing confidential information in the search results. By creating a separate account for the Search Crawl Service, you mitigate this security risk. Application pools. IIS hosts application pools, and they use the application pool account, which identifies the application pools. You can isolate applications that host sensitive data by hosting them in their own application pool.
5-6
Security Architecture in SharePoint 2010
Key Points
A security architecture describes the various elements that you require to configure security for your SharePoint infrastructure and the relationships between them. These are primarily SharePoint elements, such as SharePoint groups and permission levels. However, there are external elements that you must also consider, such as Active Directory directory service groups and user accounts. Key elements include: Service accounts. Service accounts enable SharePoint services to run and to communicate with other services. Service accounts are most often Active Directory user accounts. Permission levels. Permission levels are collections of individual permissions that you group together to simplify the process of assigning permissions for securable objects. Site collection and site permissions. Each site collection and each site in your SharePoint infrastructure has permissions that you can use to control user
5-7
access. Your security plan must incorporate guidance about how to use these permissions. Security groups. You can assign SharePoint 2010 permissions to SharePoint groups, Active Directory groups, or local Windows operating system groups. Your security plan must include guidance about which type of group is appropriate in your SharePoint infrastructure. Permission policies. Permission policies provide a centralized way to configure and manage a set of permissions that applies to only a subset of users or groups in a Web application. SSL. In addition to configuring security content via permissions, for sites that contain sensitive information, you must ensure that traffic between the client and the Web Front End (WFE) server is secure. SSL is the recommended method for encrypting such traffic.
5-8
Lesson 2
Planning for Service Accounts
SharePoint 2010 relies on service accounts to run services and service applications. You must configure these service accounts with sufficient permissions and privileges to perform their functions. However, you must not grant them so many permissions that you increase the risk of a security breach. It is particularly important to ensure that the service accounts do not have administrative privileges for the SharePoint farm, the Active Directory domain, or the local machine unless they are specifically required.
Objectives
After completing this lesson, you will be able to: List the service accounts that SharePoint 2010 uses. Plan security for service accounts. Document your plan for security for service accounts. Describe the best practices for security for service accounts.
5-9
What Are Service Accounts?
Key Points
Service accounts enable services to run. They also enable communication between the different services on which SharePoint 2010 depends. Service accounts may be part of SharePoint 2010 or they may be part of an external system. Communication between the IT teams that manage the different aspects of the IT infrastructure is crucial when you plan a SharePoint 2010 deployment, A common reason for failure when you configure security for a SharePoint deployment is lack of coordination between the Windows (Active Directory) team, the SharePoint team, and the Microsoft SQL Server database administrators (DBAs). Planning should identify the accounts that you require to deploy SharePoint 2010 and the time at which you will require them. You must ensure that you have created and granted the appropriate permissions to all of the required accounts before you begin the SharePoint deployment. The following table describes the purpose and requirements of the core service accounts that are used in a SharePoint 2010 farm.
5-10
Account SQL Server service account
Purpose SQL Server uses this account to start and run the following services: MSSQLSERVER SQLSERVERAGENT
Requirements for account The SQL Server service account must be either a local system account or a domain user account. The Setup user account must: Be a domain user account. Be a member of the Administrators group on each server on which Setup is run. Have a SQL Server login on the computer running SQL Server.
Setup user account
The Setup user account runs the following: Setup SharePoint Products Configuration Wizard
The Setup user account must be a member of the following SQL Server security roles: securityadmin fixed server role dbcreator fixed server role
Server farm account
The server farm account is used to perform the following tasks: Configure and manage the server farm. Act as the application pool identity for the SharePoint Central Administration Web site. Run the Microsoft SharePoint Foundation Workflow Timer Service.
The server farm account: Must be a domain user account. Has additional permissions that are automatically granted on Web servers and application servers that are joined to a server farm.
The server farm account is automatically added as a SQL Server login on the computer running SQL Server. The account is added to the following SQL Server security roles:
5-11
Account
Purpose
Requirements for account dbcreator fixed server role securityadmin fixed server role db_owner fixed database role for all SharePoint databases in the server farm
Search service account Search content access account
The Search service account is used as the service account for the SharePoint Foundation 2010 Search service. The SharePoint Foundation 2010 Search Service uses the SEARCH content access account to crawl content across sites.
The Search service account must have domain user account permissions. The Search content access account must: Have domain user account permissions. Not be a member of the farm administrators group.
Other Service Accounts

You can create accounts to use for specific service applications in your SharePoint infrastructure in accordance with the principle of least privilege. For example, you can create a generic account that most of the service applications use, and you can create specific accounts for service applications that you must manage more closely. You should also consider the service accounts that you use to identify application pools. Application pools contain the SharePoint Web applications. You should identify any Web applications that require isolation and create a separate account to identify the relevant application spool. Question: When would you configure the SQL Server service account as a local account?
5-12
Additional Reading
For more information about account permissions and security settings for SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200876&clcid=0x409.
5-13
Planning Security for Service Accounts
Key Points
When you plan security for the core service accounts, you must determine whether to use local or domain accounts for the services and devise a naming strategy for your accounts. You must also consider the implications of having different SharePoint environments in the same organization. For example, if you have development and staging environments in addition to your production environment, you should add a duplicate set of accounts to ensure that development and testing are valid.
Using Local or Domain Accounts

Most core service accounts must be Active Directory accounts, including the Setup user account and the Server farm account. However, some accountssuch as the SQL Server service accountmay be either local accounts or domain-based accounts. If the computer on which SQL Server is installed is not part of a domain, a local user account without Windows administrator permissions is recommended.
5-14
If the computer on which SQL Server is installed is part of a domain, you should use a minimally privileged domain account. The SQL Server service account may need to perform server-to-server activities that can be accomplished only with a domain user account. A domain administrator should create this account in your environment before you install SharePoint 2010. If your organization has a separate Active Directory management team, your planning must incorporate schedules and mechanisms for liaising with this team.
Naming Strategy
It is recommended that when you devise a naming strategy, you document it clearly and use it consistently so that each account is identifiable. Consistent naming is particularly important if there is a separate Active Directory management team and you must accurately identify each account. In organizations with multiple environmentssuch as production, development and staging environmentsthe account names should identify the environment in which the account is used. For example, the service account for service applications may be named sp-p-serviceapp in the production environment and sps-serviceapp in the staging environment.
5-15
Documenting Security for Service Accounts
Key Points
Documenting your security plan is crucial. This will help you to manage the day-today security of your SharePoint infrastructure, troubleshoot problems, and recover from disaster. The service account configurations should be part of this documentation. You can use a worksheet to document your service account configuration. You should include the following information: What is the account name? Which service or service application does the account support? Is this a managed account?
Note: Always update your documentation when you make changes to any accounts.
5-16
Best Practices for Service Accounts
Key Points
The following list describes best practices for working with service accounts: Use managed accounts. Active Directory now includes both fine-grained password policies and managed service accounts. The former enables you to require stronger, more complex, and more frequently changed passwords for important accountsincluding service accounts. The latter enables you to change a password on a service account without reconfiguring the service itself with the new password. SharePoint 2010 can use these Active Directory features to automatically reset managed account passwords, but this configuration is optional. Prior to the implementation of the automatic password change feature, updating passwords required resetting each account password in Active Directory and then manually updating account passwords on all of the services running on all the computers in the farm. To do this, you had to run the Stsadm command-line tool or use the SharePoint Central Administration Web application. Using the automatic password change feature, you can now register managed accounts and enable SharePoint 2010 to control account passwords, based on individually configured password reset schedules. You
5-17
can configure accounts used exclusively by the SharePoint farm, such as the SharePoint Farm account, SharePoint service accounts, and the application pool accounts for SharePoint Web applications, to reset automatically. Accounts that are also used by other applications, such as the SQL Service account, should not be automatically reset. Create separate service accounts for specific service applications. Creating separate service accounts for service applications that host sensitive data helps to secure your SharePoint infrastructure. By using separate service accounts, you can ensure that you do not assign the rights and permissions that these service applications require to generic service accounts that do not require them. Create separate application pool accounts for specific Web applications. Creating separate application pool accounts for service applications that host sensitive data helps to secure your SharePoint infrastructure. By using separate service accounts, you can isolate Web applications and their content to provide a more secure environment.
5-18
Lesson 3
Planning Security for Users and Groups
Designing a permission structure for users and groups that is easy to maintain and provides users with only the permissions that they require to perform their job functions is key to the security of your data. To design effective security, you must understand the structures that provide access to content in SharePoint 2010. You must consider how to use permission levels to apply permissions for sites and site collections, how best to group users, and how to determine the most appropriate groups to use. You must also decide whether to allow anonymous access and understand the impact of permission policies.
Objectives
After completing this lesson, you will be able to: List the default permission levels for team sites and publishing sites. Describe site collections and site permissions. Plan permission assignment.
5-19
Plan access for authenticated users and anonymous users. Plan access policies.
5-20
Permission Levels
Key Points
A permission level is a predefined set of permissions that allows users to perform a set of related tasks. For example, the Read permission level includes the View Items, Open Items, View Pages, and View Versions permissions (among others), all of which are required to read documents, items, and pages of a SharePoint site. SharePoint 2010 includes five permission levels by default. To simplify the administration of your security plan, you should use the default permission levels whenever possible. However, you can customize the permissions in the default permission levels, with the exception of the Limited Access and Full Control permission levels. You can also create customized permission levels that contain only the specific permissions that you require. Although you cannot directly edit the Limited Access and Full Control permission levels, you can make individual permissions unavailable for the entire Web application. This removes these permissions from the Limited Access and Full Control permission levels.
5-21
The different SharePoint 2010 site templates have different default permission levels. For example, the following table lists the default permission levels for Team Sites in SharePoint 2010.
Permission level Limited Access Description Allows access to shared resources in the Web site so that users can access an item in the site. Designed to be combined with fine-grained permissions to give users access to a specific list, document library, item, or document without giving them access to the entire site. Cannot be customized or deleted. Allows read-only access to the Web site. Permissions included by default Browse User Information Use Client Integration Features Open
Read
View Items Open Items View Versions Create Alerts View Application Pages Use Self-Service Site Creation View Pages Browse User Information Use Remote Interfaces Use Client Integration Features Open
Contribute
Create and edit items in the existing lists and document libraries. Create lists and document libraries and edit pages in the Web site.
Read permissions, plus: Manage Unsafe Content Approve permissions, plus: Manage Lists Add and Customize Pages Apply Themes and Borders Apply Style Sheets
Design
Full Control
Allows full control of the scope.
All permissions
5-22
If you use a site template other than the Team Site template, you will see a different list of default SharePoint groups. For example, the following table shows additional permission levels that are provided with the Publishing template.
Permission level Restricted Read Description Permissions included by default
View pages and documents. View Items For publishing sites only. Open Items View Pages Open
View Only
View pages, list items, and documents. If the document has a server-side file handler available, users can only view the document by using this file handler.
Limited Access permissions, plus: View Items View Versions Create Alerts Create Mobile Alerts View Application Pages
Approve
Edit and approve pages, list items, and documents. For publishing sites only.
Contribute permissions, plus: Override Checkout Approve Items
Manage Hierarchy
Create sites and edit pages, list items, and documents. For publishing sites only.
Design permissions (minus the Approve Items permission), plus: Manage Permissions View Usage Data Create Subsites Manage Web Site Manage Alerts
Additional Reading
For more information about how to determine permission levels and groups for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200877&clcid=0x409.
5-23
Site Collections and Site Permissions
Key Points
By using permission levels, you can apply permissions at all levels in your SharePoint hierarchy to control access to content. You can give permissions for a specific site collection, site, list or library, folder, document, or item to users and groups. Consider how tightly you want to control permissions for the site or site content. For example, you may want to control access at the site level, or you may require more restrictive security settings for a specific list, folder, or item. Your security plan should include this information and the rationale behind it. For sites that have a definite security model and structuresuch as Human Resources, Communications, Portal, or Document Centeryour plan should cover the permissions structure in detail. For team and project sites, you should include general security practices and guidelines in the security plan. If your design requires local or departmental administrators to manage site collections, you can make them site collection administrators. Site collection administrators have the Full Control permission level on all Web sites in a site
5-24
collection. Site collection administrators have access to content in all sites in that site collection, even if they do not have explicit permissions on that site. Users who create sites automatically become site owners. They can perform administration tasks for the site and for any list or library in that site. Site owners receive e-mail notifications for events, such as the pending automatic deletion of inactive sites and requests for site access. If you require users to administer sites that they did not create, you can add them to the relevant site owners group.
Default Site Permissions

When a site collection is created, default groups are also created that receive specific permission levels for sites in the site collection. You should plan to use these defaults whenever possible to simplify your security plan. The groups that SharePoint creates vary depending on the template that is used. The following table describes these groups and the permission levels that SharePoint grants for team sites.
Group name Owners Designers Default permission level Full Control Design Description Administrator access. Create lists and document libraries, edit pages, and apply themes, borders, and style sheets. Add, edit, and delete items in existing lists and document libraries. Read-only access. View pages, list items, and documents.
Members
Contribute
Visitors Viewers
Read View Only
Additional Reading
For more information about how to plan site permissions for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200878&clcid=0x409.
5-25
Planning Permission Assignment
Key Points
There are some key points that you must consider when you plan how to assign permissions for SharePoint sites.
Assigning Permissions
Consider the following points when you plan how to assign permissions for site collections and sites: You must decide which groups to use to categorize and manage your users. Groups do not have any permissions until you assign them a permission level for a specific site or for specific site content. When you assign permission levels to SharePoint groups at the site collection level, by default, all sites and site content inherit those permission levels. You can use either a Windows security group or a SharePoint group, such as Site Owners, Site Members, or Site Visitors. You create and manage SharePoint groups at the site collection level. SharePoint assigns each group a default permission level, but you can customize the permission level for any group.
5-26
A site collection administrator or a user with Manage Permissions privileges can define a SharePoint group, and can use this group to secure objects in a single site collection only. SharePoint groups that you create at the site collection level are available to any subsite or other securable object in the site collection.
You must decide whether to use Windows security groups or SharePoint groups. One benefit of using Windows groups is that the group membership is updated when the user account changes. For example, if you delete the user account, the Windows group membership is automatically updated. However, using Windows groups requires Windows or Active Directory administrative permissions. SharePoint administrators can manage SharePoint groups, but may not be able to view the membership of Windows groups, depending on their Windows or Active Directory permissions. To ensure that the structure of your security group is easily extensible and permissions are assigned consistently, use the following strategy: Make the user a member of an Active Directory group. Make that Active Directory group a member of a SharePoint group and then assign permissions to the SharePoint group. Alternatively, if a site collection administrator manages the structure of your security groups, make the user a member of a SharePoint group and then assign permissions to the SharePoint group.
Inheriting Permissions
Inheriting permissions is the default behavior for child objects within the SharePoint hierarchy and is the easiest way to manage a group of Web sites. However, if a subsite inherits permissions from its parent and the parent sites permissions change, the subsites permissions will also change. This change may compromise security or prevent users from accessing content. If you want to change permissions for the subsite only, you must first stop inheriting permissions from the site and then create fine-grained permissions on the subsite. Creating unique permissions copies the groups, users, and permission levels from the parent site to the subsite and then breaks the inheritance. If you restore inherited permissions, the subsite will inherit its users, groups, and permission levels from the parent site.
Checking Effective Permissions

Many SharePoint sites give all authenticated users (the NTAUTHORITY\AUTHENTICATED USERS domain group) access to at least
5-27
some site content. If you want more restricted access, you must determine exactly which permissions to give to authenticated users and which site content they can access. SharePoint 2010 uses effective permissions to determine permissions for a user or group on all resources in a site collection. You can now find both the user's directly assigned permissions and the permissions that are assigned to any groups of which the user is a member by using the Check Permissions command.
Best Practices
When you plan permissions, you must balance ease of administration and performance against the requirement to control access to individual items. If you use fine-grained permissions extensively, you will spend more time managing the permissions, and users may experience slower performance when they try to access site content. Although it is often necessary to apply individual permissions, it is generally recommended that you should avoid this approach if you can provide the same access by using a group.
Additional Reading
For more information about security planning for sites and content for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200879&clcid=0x409.
5-28
Planning Access for Authenticated Users and Anonymous Users
Key Points
When you design your security plan, you should consider how you can make the most effective use of specialized groups and users. Specifically, you must decide whether to allow access to authenticated users or anonymous users.
Authenticated Users
If your security plan requires all authenticated users in your domain to have access to a particular site, you should grant access to the site to the Domain Users security group. All members of your domain belong to the Domain Users group. Therefore, you must be cautious when you use this group to assign permissions, especially if you are granting permissions that enable the user to change the content of a site. By granting permissions to the Domain Users group, you may be able to avoid the riskier strategy of enabling anonymous access for the site.
Anonymous Access
You can enable anonymous access so that users can view pages anonymously. You typically configure anonymous access for publishing and extranet sites such as
5-29
www and partner sites. You can design your SharePoint sites so that most allow for anonymous viewing but require authentication when someone wants to edit the site or browse into a restricted area. You grant anonymous access at the Web application level, and you generally configure it at the time that you create the Web application. It is possible to enable anonymous access later, but it is most convenient to do it while you create the Web application. If you enable anonymous access for the Web application, site administrators can decide whether to: Grant anonymous access to a site. Grant anonymous access only to lists and libraries. Block anonymous access to a site completely.
Anonymous access is based on the anonymous user account on the Web server. SharePoint does not create or maintain this account; IIS creates and maintains it. The default name for the anonymous user account is IUSR. Allowing access to a site, or to lists and libraries, grants the View Items permission to the IUSR account. To improve security for sites, lists, or libraries, you should not enable anonymous access. Enabling anonymous access allows users to contribute to lists, discussions, and surveys, which may reduce server disk space and adversely affect other resources. Anonymous access also enables anonymous users to discover potentially sensitive informationsuch as e-mail addressesand any content that is posted to lists, libraries, and discussions.
Additional Reading
For more information about how to choose security groups for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200880&clcid=0x409.
5-30
Planning Policies
Key Points
A Web application is an IIS Web site that acts as a logical container for your site collections. Each Web application can contain thousands of site collections; managing permissions for these site collections individually would quickly become cumbersome, time-consuming, and prone to error. To avoid this scenario, you can use permission policies to help you to mange permissions for Web applications and hence the site collections that they contain. A permission policy is a set of permissions that you can apply to a subset of users or groups in a Web application.
Permission Policy
A permission policy specifies the permission level that applies to the users and groups that the policy affects. You can specify the following permission levels: Full Control Full Read Deny Write Deny All
5-31
You can create a permission policy level to customize a set of permissions for a specific group.
User Policy
You can use a user policy to specify the permissions that apply to a user who accesses a site. If the site is in a Web application that has multiple zones, you can choose the zone where the policy applies. By extending the Web application into multiple zones, you create a separate IIS Web site that serves the same content, but with a unique URL and authentication type. A user policy enables you to add users to a permission policy, edit the policy settings, and delete users from a permission policy. For example, you may want to add users to a permission policy to ensure that all users are accessing content with the same set of permissions.
Anonymous Policy
The anonymous policy allows you to enable or disable anonymous access for a Web application. If you enable anonymous access for a Web application, site administrators can then grant or deny anonymous access at the site collection, site, or item level. If you disable anonymous access for a Web application, anonymous users cannot access sites in that Web application. Anonymous access is enabled in three places: IIS, the Web application anonymous access policy, and the site collection or site. Question: How do permission policies, user policies, and anonymous policies relate to each other?
Additional Reading
For more information about how to manage permission policies for a Web application for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200881&clcid=0x409.
5-32
Lesson 4
Planning for SSL
When you create a security policy, a priority area to consider is providing encryption between the client and SharePoint 2010. Without this encryption, your data will be vulnerable to interception in transit. Before you design a security plan that requires SSL communication, you must consider the possible performance impact and how to mitigate it. You must also consider some of the common configuration options such as obtaining certificates, identifying which Web applications you must secure, and deciding whether to change port mappings.
Objectives
After completing this lesson, you will be able to: Describe the use of SSL in a SharePoint 2010 infrastructure. List factors to consider when planning for SSL in a SharePoint 2010 infrastructure.
5-33
Why SSL?
Key Points
In most scenarios, you should use SSL encryption to secure communication between client computers and servers. Secure client-server communication can be particularly important in the following situations: You provide partners with access to an extranet environment. Your employees require remote access to data. You use basic authentication or forms authentication. You store sensitive or mission-critical data in your SharePoint application.
The use of SSL can create performance overheads on both your WFE servers and your client browsers. Therefore, it may not be appropriate to encrypt all clientserver communication. However, if SSL encryption creates a performance bottleneck, you can use SSL acceleration devices to alleviate the burden that the encryption algorithms place on the processor.
5-34
SSL Planning Factors
Key Points
You should plan for the implementation of SSL as part of your overall SharePoint security plan. You must determine which of your Web applications require SSL encryption of network traffic. You must also decide whether you will provide certificates via an internal Certificate Authority (CA) or purchase them from an external vendor. Finally, you should consider whether to use standard port mappings for SSL or specify custom port mappings.
Web Applications
Not all sites and site collections will require SSL encryption. You must determine which sites and site collections require this type of security, such as sites that expose sensitive financial, HR, or research and development data. If you have Web applications for sites that expose sensitive data, you should configure them for SSL. To make this easier, you may be able to group the sites that require SSL into the same Web application, although this will depend on the nature of the sites. You must define your requirements for encryption when you design your security plan for SharePoint 2010.
5-35
Certificates
To set up SSL encryption, you must first obtain a digital certificate. You can either submit a request to an internal CA, or you can use Certificate Services (an optional component of Windows Server 2008) to create your own certificates for internal use. You must then install the certificate in IIS and configure the Web site to require secure communication.
Port Mappings
You should limit Internet-facing ports on your WFE servers to port 80 for HTTP and port 443 for HTTPS. You can assign a nonstandard port for Web applications by using SSL over HTTPS, but users must specify that port number to connect to the site. This may cause extra administrative effort.
5-36
Lab: Designing a Security Plan
Exercise 1: Designing for Least-Privilege Security

Scenario
Your team must develop a security plan for the Contoso, Ltd SharePoint 2010 deployment that is based on the existing logical and physical designs. The plan must conform to the principle of least privilege. You should begin by reviewing the available documentation. The main task for this exercise is as follows: 1. 2. Read the supporting information. Complete the SharePoint 2010 Security Planning worksheet.

1. Read the lab scenario.
5-37
2. 3. 4. 5.
Log on to 10231A-NYC-DC1-05 as CONTOSO\Ed with the password Pa$$w0rd. In the E:\Labfiles\Lab05\Starter folder, review the Contoso Business Requirements.doc file. In the E:\Labfiles\Lab05\Starter folder, review the Logical Architecture Diagram - Solution.vsd file. In the E:\Labfiles\Lab05\Starter folder, review the SharePoint 2010 Service Applications Planning Worksheet - Solution.xlsx file.
Task 2: Complete the SharePoint 2010 Security Planning worksheet

In the E:\Labfiles\Lab05\Starter folder, complete the worksheet in the SharePoint 2010 Security Planning Worksheet.xlsx file.
Exercise 2: Identifying and Resolving Potential Security Issues

Scenario
Your team must review the existing lab environment and ensure that it adheres to your security plan. The main tasks for this exercise are as follows: 1. 2. 3. Apply least privilege to the farm account and reset IIS. Create and register a new service account as a managed service account and modify which service account is used for an application pool. Remove an account from the managed accounts list and reset IIS.
Task 1: Apply least privilege to the farm account and reset IIS
1. 2. 3. In Active Directory Users and Computers, remove the SharePoint server farm account from the Domain Admins group. In SharePoint 2010 Central Administration, configure the farm account to use CONTOSO\sp-farm. From an administrator command prompt, reset IIS.
5-38
Task 2: Create and register a new service account as a managed service

account and modify which service account is used for an application pool
1. In Active Directory Users and Computers, in the Managed Service Accounts container, create a new service account by using the information in the following table.
Value SharePoint App Pool Service Account sp-apppool Pa$$w0rd cleared
Option Full name User logon name Password User must change password at next logon
2.
In SharePoint 2010 Central Administration, register the managed account by using the information in the following table.
Value CONTOSO\sp-apppool Pa$$w0rd
Option User name Password
3.
Configure the SharePoint-80 Web application pool to use the CONTOSO\spapppool account.
Task 3: Remove an account from the managed accounts list and reset
IIS
1. 2. In SharePoint 2010 Central Administration, remove the contoso\administrator account from the managed accounts list. From an administrator command prompt, reset IIS.
5-39
Exercise 3: Granting Read Access to the Production Auditors Group

Scenario
For compliance reasons, the production audit team requires access to all information in the Contoso, Ltd intranet. The main task for this exercise is to grant a group Full Read access to a Web application.
Task 1: Grant a group Full Read access to a Web application

In SharePoint 2010 Central Administration, grant the CONTOSO\production auditors Full Read access to the SharePoint 80 Web application.
5-40
Review Questions
1. 2. 3. What are the key elements of a security plan for SharePoint 2010? How should you use SharePoint groups to secure a site? How does SSL help to secure site content?
Best Practices Related to Designing a Security Plan

Supplement or modify the following best practices for your own work situations: Use the principle of least privilege when you apply permissions to users and groups. Consider all elements of the SharePoint 2010 security architecture when you design your security plan.
5-41
Apply security at the highest level possible (site or site collection) and allow permission inheritance to give users permission at lower levels of the hierarchy. Always keep your security documentation up to date. You may require it to help you troubleshoot an excessive access issue or rebuild the security environment in the case of a catastrophic failure.
Planning Authentication
6-1
Module 6
Contents:
Lesson 1: Overview of Authentication Lesson 2: Planning a Claims-Based Authentication Topology Lesson 3: Selecting Authentication Methods Lab: Planning Authentication 6-3 6-16 6-25 6-36
6-2
Module Overview
To be secure and usable, Microsoft SharePoint 2010 must be able to identify users who are attempting to access content and resources. After it identifies the user, SharePoint 2010 must validate the user to ensure that the user is permitted to access the requested resources. The process of identifying and validating the user is known as authentication, and designing an all-encompassing authentication plan is a vital part of your SharePoint 2010 infrastructure design.
Objectives
After completing this module, you will be able to: Describe the different authentication and authorization methods that SharePoint 2010 uses. Describe claims-based authentication in SharePoint 2010. Select the most appropriate authentication method for a given SharePoint 2010 design.
6-3
Lesson 1
Overview of Authentication
You must be familiar with the relevant authentication methods before you can design an authentication plan. This lesson provides an overview of the authentication methods that you can use in a SharePoint 2010 infrastructure.
Objectives
After completing this lesson, you will be able to: Describe NT LAN Manager (NTLM) authentication. Describe Kerberos authentication. Describe client certificate authentication. Describe anonymous authentication. Describe claims-based authentication.
6-4
Describe forms-based authentication. Describe how the Secure Store Service provides single sign-on (SSO) authentication.
6-5
NTLM Authentication
Key Points
NTLM is a secure protocol that supports user credential encryption and transmission over a network. NTLM encrypts user names and passwords before it sends the encrypted credentials over the network. NTLM authentication is required in networks where the server receives requests from client computers that do not support Kerberos authentication. NTLM is the authentication protocol that is used in Windows NT and Windows 2000 server workgroup environments, which have no Active Directory directory service domain controller. NTLM is used in mixed Windows 2000 Active Directory domain environments that must authenticate Windows NT systems. In domains where no Windows NT domain controllers exist, you can raise the domain functional level. NTLM is thereby disabled, and Kerberos becomes the default authentication protocol for the enterprise. If your environment includes computers that require NTLM authentication, you must incorporate it into your authentication plan.
6-6
Kerberos Authentication
Key Points
Kerberos is the core authentication protocol in Active Directory domains. A Kerberos authentication server grants a ticket in response to a client computer authentication request, if the request contains valid user credentials and a valid service principal name (SPN). The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must be able to access a Key Distribution Center (KDC), which distributes shared secret keys to enable encryption. The client and server computers must be able to access Active Directory Domain Services. An important consideration for enterprises with multiple forests is that the KDC cannot be accessed across forest boundaries. Further planning and configuration is required if client and server are in different forests to the KDC. To implement Kerberos authentication, the client application must provide an SPN, a user principal name (UPN), or a NetBIOS account name as the target name. If the client application cannot provide this information, it may be necessary to plan for the use of NTLM authentication. SharePoint farms typically use Kerberos and NTLM; if Kerberos authentication fails, SharePoint will automatically attempt to use NTLM authentication.
6-7
If you deploy a SharePoint 2010 farm that uses Kerberos authentication exclusively, you must configure Kerberos authentication to support the following functionality: Communication between SharePoint 2010 and Microsoft SQL Server database software. Access to the SharePoint Central Administration Web application. Access to other Web applications such as a portal site Web application or a My Site Web application.
Question: What must the client provide in a Kerberos authentication request?
Additional Reading
For more information about how to configure Kerberos authentication, see http://go.microsoft.com/fwlink/?LinkID=200882&clcid=0x409. For more information about how to use Kerberos for SharePoint authentication, see http://go.microsoft.com/fwlink/?LinkID=201237&clcid=0x409.
6-8
Client Certificate Authentication
Key Points
Client-certificate authentication supports the exchange of public key certificates by using Secure Sockets Layer (SSL) encryption over HTTP. Client certificates are issued by a Certificate Authority (CA), which may be internal or external, and they must conform to the public key infrastructure (PKI). To implement client certificate authentication, you must select Windows authentication in Central Administration, configure Internet Information Services (IIS) for certificate authentication, enable SSL, and obtain and configure certificates from a CA.
6-9
Anonymous Authentication
Key Points
Anonymous authentication enables users to find resources in the public areas of Web sites without providing authentication credentials. Anonymous authentication enables anyone with an Internet connection to browse a Web site; therefore, you must plan for anonymous access extremely carefully. Anonymous authentication is enabled at the Web application level at the time of creation. Site administrators for sites in the Web application can then grant or block anonymous access to their site. Anonymous access relies on the anonymous user account on the Web server; IIS creates and manages this account, not the SharePoint site. Allowing anonymous access to a site grants permissions to the anonymous user account. Review your business requirements, your logical architecture design documentation, and your security plan to determine which sites should be configured for anonymous authentication. You must ensure that your authentication plan maps anonymous authentication to only those Web applications that contain sites that require anonymous access.
6-10
Claims-Based Authentication
Key Points
SharePoint 2010 supports claims-based authentication, which enables SharePoint applications to authenticate a user without requiring the user to disclose more information than necessary. If SharePoint 2010 trusts the authentication authority that validates the claims of a user, it will allow the user to be authenticated. Your SharePoint authentication plan will include claims-based authentication if: You need to enable authentication across Windows-based systems and systems that are not based on the Windows operating system. Your SharePoint infrastructure must support delegation of user identity between applications. Your SharePoint infrastructure requires multiple forms of authentication on a single zone.
6-11
In SharePoint Server 2010, you must choose between claims-based authentication and classic-mode authentication when you create a Web application. If you choose classic-mode authentication, and later want to convert to claims-based authentication, you can use Windows PowerShell to reconfigure the Web application. Alternatively, you can delete the Web application, without deleting the supporting application pool or database, and then re-create it by using claimsbased authentication.
6-12
Forms-Based Authentication
Key Points
Your SharePoint 2010 infrastructure may call for users who do not belong to a Windows-based identity management system, or who belong to an external system, to be authenticated. Forms-based authentication provides this functionality. Forms-based authentication is an identity management system that is based on ASP.NET membership and role provider authentication methods. You can use forms-based authentication to authenticate user accounts. However, the SharePoint 2010 service accounts that you use to connect to SQL Server database software and run the farm must be Windows accounts, even when you use alternative methods of authentication to authenticate users. In SharePoint 2010, forms-based authentication is only available when you use claims-based authentication.
Authenticating Against Credentials

The forms-based authentication provider supports authentication against credentials stored in Active Directory, in a database such as a SQL Server database, or in a Lightweight Directory Access Protocol (LDAP) data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms-based
6-13
authentication enables user authentication that is based on validation of credential input from a logon form. Unauthenticated requests are redirected to a logon page, where the user must provide valid credentials and submit the form. If the request can be authenticated, the system issues a cookie that contains a key for reestablishing the identity for subsequent requests.
Configuring Forms-Based Authentication

Using forms-based authentication as an authentication method for users requires some configuration. You must register the membership provider in the Web.config file, and you can also register a role manager. SharePoint 2010 uses the ASP.NET role manager interface to gather group information about the current user; the authorization process treats each ASP.NET role as a domain group. You can also manage membership providers and role managers through SharePoint 2010 Central Administration. You must register the membership provider and the role manager in the Web.config file for the Central Administration site in addition to registering these in the Web.config file for the Web application that hosts the content. Integrating with forms-based authentication places additional requirements on the authentication provider. In addition to registering the various elements in the Web.config file, you must program the membership provider, role manager, and HTTP module to interact with SharePoint 2010 and ASP.NET methods. Forms-based authentication passes credentials over HTTP, so using SSL to encrypt this traffic is highly recommended.
Additional Reading
For more information about how to plan authentication methods, see http://go.microsoft.com/fwlink/?LinkID=200884&clcid=0x409. For more information about how to configure forms-based authentication in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=201239&clcid=0x409.
6-14
Secure Store Service Authorization
Key Points
In SharePoint 2010, the Secure Store Service replaces the SSO feature. The Secure Store Service is a claims-aware authorization service that includes a secure database for storing credentials that are associated with application IDs. Applications use these application IDs to authorize access to external data sources and other resources. The Secure Store Service runs on an application server, providing a database that is used to store user identities and passwords for application IDs. The Secure Store Service provides support for storing the credentials of multiple systems by using multiple application IDs.
Application IDs and Mappings

Each Secure Store Service entry includes an application ID that is used to retrieve a set of credentials from the secure store database. Application IDs are used to map users or groups to credential sets. Applications use application IDs to retrieve credentials from the secure store database on behalf of a user. The application can then use the retrieved credentials to access a data source.
6-15
In a group mapping, every user who is a member of a specific domain group is mapped to the same set of credentials. In an individual mapping, each individual user is mapped to a unique set of credentials.
Secure Store Service Mappings

Individual mappings are useful if you require logging information about individual user access to shared resources. For group mappings, a security layer checks group credentials for multiple domain users against a single set of credentials for a resource; an application ID that is stored in the secure store database identifies this resource. Group mappings are easier to maintain than individual mappings and can provide improved performance.
6-16
Lesson 2
Planning a Claims-Based Authentication Topology
SharePoint 2010 incorporates a new, more powerful and flexible authentication model that works with any corporate identity system, including Active Directory, LDAP-based directories, application-specific databases, and new user-centric identity models such as LiveID. Claims-based authentication is built around the concepts of claims, identities, and identity providers. Claims-based authentication provides a common way for applications to acquire identity information from users inside their organization, in other organizations, or on the Internet. Identity information is contained in a security token. A security token contains one or more claims about the user. This metadata about the user stays with them throughout their session. Claims-based authentication is new to SharePoint 2010, so this lesson covers claims-based authentication architecture and topologies in detail.
6-17
Objectives
After completing this lesson, you will be able to: Describe the claims-based authentication architecture. Describe the claims-based authentication topology for a single farm. Describe the claims-based authentication topology for multiple farms.
6-18
Claims-Based Authentication Architecture
Key Points
The architecture of claims-based authentication consists of claims, identities, and identity providers. The relationship between these elements is described in the following sections.
Claims
A claim is a piece of information that is asserted about an object. The assertion is made either by the subject itself or by another object. Usually, users make claims about themselves, although applications, computers, and external systems can also make claims. Each claim is information that identifies the object: it may be an email address, a user name, or membership of a group or role. The subject may assert several claims, presenting several pieces of information to gain access to multiple resources. Although claims are attributes of an object, the term claim is used because of the way in which the information is presented. Claims are a proactive way for the subject to present information to be used for validation. The application that receives the claims does not have to look up the required attributes in a directory service; the requesting object presents them.
6-19
Each claim is made by an issuer, and the application trusts the claim only as much as it trusts the issuer. For example, a claim that a domain controller makes is trusted more than a claim that the user makes. The claims application programming interface (API) has an issuer property that enables the application to find out who issued the claim.
Identities
A set of claims is given one or more values and then packaged in security tokens that a Security Token Service (STS) issues. Tokens express information about a specific entity. This information consists of one or more claims, each of which contains some information about the subject to which this token applies. The claims in a token commonly contain many sorts of information; claims are not limited to, and may not necessarily include, a subject's name. An application that receives a token does not automatically accept the information that it contains. Instead, a received token is validated before an application uses any claims that it contains. The key concept is that a claim is not just a unique identifier that identifies the resource, application, or user. It is a set of values that is used to describe the resource, application, or user. The claims are also used to authorize access.
Identity Providers
The identity provider is the STS, which packages and then issues the claim. The STS gathers its information from an attribute store that contains the information about the user. The attribute store can be Active Directory Domain Services, a SQL Server database, an LDAP store, or a Windows Live ID. The content of each security token is determined by the requirements of the authentication requests that are agreed upon by an STS and the SharePoint application. An agreed-upon collection of claims and claim rules is a policy. Policies are available in a policy store and are accessed by an STS. The STS functions as an identity provider and creates the token that encapsulates the subjects claim. If the STS and the Web application are in the same SharePoint farm, the STS functions as a local Identity Provider STS (IP-STS). If the STS and the Web application are in different farms, the STS functions as a Relying Party SPS. If the IP-STS and the Web application are in the same SharePoint farm, the IP-STS provides security tokens to authenticated users whose attributes are available in local attribute stores.
6-20
If the IP-STS and the Web application are in different SharePoint farms, a Relying Party STS is used, which has a trust relationship with an IP-STS. A Relying Party STS and a Web application are in different SharePoint farms. As a result of this trust relationship, the Relying Party STS can authorize an external user whose credentials are not stored locally, so long as an IP-STS issues a valid security token for that user.
6-21
Authentication Topologies for Single Farms
Key Points
The topology for claims-based authentication in a single farm consists of a local STS, which is local to the SharePoint farm. The authentication process is as follows: 1. 2. 3. 4. An internal user whose credentials are directly accessible by the local STS requests authentication. The Web application responds to the authentication request with a redirect to the local STS. The authentication request is submitted to, and processed by, the local STS. The STS finds the policy for the requesting Web application in the policy store and creates a token for the requesting user by using identity assertion values in the attribute store.
6-22
5. 6.
A valid security token is returned to the user and then submitted to the Web application. The Web application authenticates the user. In this example, the Web application returns a cookie to the user.
6-23
Authentication Topologies for Multiple Farms
Key Points
The topology for claims-based authentication in a multiple farm infrastructure consists of a local STS, which is local to the SharePoint farm, and a partner STS, which is in a separate SharePoint farm. There is a trust relationship between the SharePoint farms. The authentication process is as follows: 1. 2. 3. 4. 5. An external user whose credentials are not directly accessible by the local STS requests authentication. The Web application responds to the authentication request with a redirect to the partner STS. The authentication request is submitted to the partner STS. The partner STS creates an IP-STS token for the user and submits it to the local STS. The local STS decrypts the IP-STS token, creates a Relying Partner STS (RPSTS) token, and returns it to the external user.
6-24
6. 7.
The RP-STS token is then submitted to the Web application. The Web application authenticates the user. In this example, the Web application returns a cookie to the user.
6-25
Lesson 3
Selecting Authentication Methods
An effective authentication plan incorporates the appropriate authentication methods for each Web application in your SharePoint 2010 architecture. To produce an authentication plan, you must be able to match authentication methods to business requirements. You must evaluate authentication methods and understand how to implement different forms of authentication.
Objectives
After completing this lesson, you will be able to: Explain how to match authentication methods to business requirements. Choose between classic mode and claims-based authentication. Evaluate authentication methods. Explain when to implement multi-mode authentication. Describe how to plan authentication for farm zones. Explain how to plan authentication testing.
6-26
Matching Authentication Methods to Business Requirements
Key Points
When you design the authentication plan for your SharePoint 2010 architecture, a key task is to match the authentication methods that you will use to the business requirements that you must meet. Business requirements come in many forms, from interviews with stakeholders and reports of end-user usability issues to documentation from previous systems. Part of your task is to interpret this data and reformat it into a consistent format that provides the basis for an authentication plan. When you match authentication methods to business requirements, look for keywords and phrases that indicate who should be able to access SharePoint content. For example, Internet-facing and public imply that anonymous access should be enabled for certain parts of the SharePoint site. Private, secure area, and log on all imply that valid user credentials must be provided before the content is accessible.
6-27
You can determine authentication methods from business requirements documentation. Phrases such as partners, external users, and customers all indicate that users who are not members of your internal domain will require some level of access. Often external users will be authenticated through claims-based methods such as forms-based authentication. You must determine how to provide them with access before you begin to create SharePoint Web applications, because you select the authentication method for the Web application at the time that you create it.
6-28
Demonstration: Selecting Classic Mode or Claims-Based Authentication
Key Points
In this demonstration, you will see how to: Select claims-based or classic mode authentication. Identify authentication providers for Web applications.
6-29
Evaluating Authentication Methods
Key Points
Understanding the advantages, recommendations, and trade-offs for each specific authentication method can help you to determine which methods to use in your environment. The following table highlights the advantages, recommendations, and disadvantages for each authentication method.
Authentication method Advantages Windows-based NTLM or Kerberos Enables you to authenticate users by using existing Active Directory accounts. Enables you to take advantage of Active Directory groups when you configure SharePoint Server 2010 authorization. Simplifies user management. Enables you to avoid writing custom code. Trade-offs Some IIS authentication protocols are not supported by all Web browsers.
6-30
Authentication method Advantages Client certificates Enables you to authenticate users with digitally signed certificates. Enables users to find resources in the public areas of Web sites without providing authentication credentials.
Trade-offs Requires you to obtain and distribute certificates for clients. Enables anonymous access to your SharePoint resources; use with caution. Requires additional planning and configuration. Configuration and management requires additional planning and training.
Anonymous Authentication
Claims-based
Enables you to authenticate users from a system not based on Windows, such as a database. Enables subjects to make claims about themselves. Claims can include a user name, a role, an employee ID, and a variety of other attributes that applications use to determine authorization and permission levels.
Forms-based
Enables you to set up SharePoint Server 2010 in an environment that does not require Windows accounts. Enables you to authenticate against two or more different identity management systems when you create partner applications. Enables you to implement a custom authentication scheme by using arbitrary criteria. Enables the authentication of users coming from the Internet.
Requires customization of the Web.config file. Subject to replay attacks for the lifetime of the cookie, unless you use SSL Transport Layer Security (TLS).
6-31
Double-Hop Scenario
The double-hop scenario in SharePoint 2010 describes a situation that can arise when NTLM authentication is used. In the double-hop scenario, IIS attempts to pass a users NTLM credentials to a service that is not running directly on the Web server or is running on a server that is not part of the requesting servers farm. This type of authentication is not permitted in the Microsoft .NET Framework, because it is not secure. NTLM only authenticates the client, not the server; therefore, the Web server can pass the client credentials to any other service or client without the knowledge of the original requesting client. Kerberos authentication provides a solution to this issue, but it requires some configuration. Kerberos allows for impersonation and delegation, which gives the Web server permission to authenticate to another service on behalf of the user. In addition, Kerberos can authenticate both the client and the server, which ensures that requests are directed only to those servers and services that the end user trusts. This feature is not active by default. You must configure the service accounts running on the Web server to use impersonation by enabling the trust for delegation settings for both the service account and server in Active Directory Users and Computers.
6-32
Multi-Mode Authentication
Key Points
Your logical architecture design may require two different types of users to access the same SharePoint site, for example, internal employees and external partners. In this scenario, you must plan to configure more than one authentication method. You can configure Web applications in SharePoint Server 2010 to be accessed by up to five different authentication methods or identity management systems. The diagram on the slide illustrates a Web application that is configured to be accessed by users from two different identity management systems. Internal employees are authenticated by using one of the standard Windows authentication methods. Partners are authenticated against a separate, forms-based identity management system. If your authentication plan must accommodate this type of scenario, you must plan to perform some additional configuration of the Web application. You must configure additional zones for the Web application for it to be accessed by more than one authentication system. Additional zones provide different logical paths to gain access to the same application. In the scenario on the slide, partners access the application through the Internet, and internal employees access the application
6-33
directly through the intranet. When the new zones have been added, you can configure separate authentication methods. In this case, the default zone is the zone that internal employees use, and the Internet zone is configured for partner access. The Internet zone uses forms-based authentication to authenticate partners against the alternate identity management system.
6-34
Planning Authentication for Farm Zones
Key Points
If you plan to implement more than one authentication method for a Web application by using zones, use the following guidelines: Use the Default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and other security policies of the Default zone are applied. The Default zone is the zone that is created when you initially create a Web application. Typically, the most secure authentication settings are designed for end-user access. Consequently, end users are likely to access the Default zone. Use the minimum number of zones that the application requires. Each zone is associated with a new IIS site and domain for accessing the Web application. Only add new access points when these are required. If you want content in the Web application to be included in search results, ensure that at least one zone is configured to use NTLM authentication. The index component requires NTLM authentication to crawl content. Do not create a dedicated zone for the index component unless necessary.
6-35
Planning Authentication Testing
Key Points
Your SharePoint 2010 authentication plan must include a detailed plan for testing the authentication design and configuration. Testing validates the authentication plan and enables you to identify any issues before you deploy SharePoint 2010 to a wider environment. You should plan to use a lab environment for initial authentication testing. When initial testing is complete, you can verify that authentication functions as planned in a staging environment.
6-36
Lab: Planning Authentication
Exercise 1: Planning Authentication for Contoso, Ltd

Scenario
Contoso, Ltd must support varying degrees of user authentication to its sites. Internal Contoso, Ltd users should be able to access the local intranet and partner extranet without providing additional credentials. External partners who are not members of the Contoso, Ltd domain must be able to access the extranet site securely. The public-facing Web site should be open to potential customers, and existing customers should be able to log on to secure areas. Finally, the research team would like to use the RSS Web Part to access an RSS feed on a SharePoint list that requires authentication. Based on the business requirements, you must design an authentication strategy. The main tasks for this exercise are as follows: 1. 2. Complete the Planning Authentication Methods worksheet. Complete the Logical Architecture Diagram with Authentication diagram.
6-37
Task 1: Complete the Planning Authentication Methods worksheet

1. 2. 3. Read the lab scenario. Log on to 10231A-NYC-DC1-06 as CONTOSO\Ed with the password Pa$$w0rd. In the E:\Labfiles\Lab06\Starter folder, complete the worksheet in the Planning Authentication Methods Worksheet.xlsx file.
Task 2: Complete the Logical Architecture Diagram with

Authentication diagram
1. 2. 3. Read the lab scenario. In the E:\Labfiles\Lab06\Starter folder, review the completed Planning Authentication Methods Worksheet.xlsx file. In the E:\Labfiles\Lab06\Starter folder, complete the diagram in the Logical Architecture Diagram with Authentication.vsd file.
Exercise 2: Enabling Claims-Based Authentication

Scenario
You must ensure that your lab environment is configured correctly. You have created the SharePoint Internet site (www.contoso.com), and now you want to use it to test claims-based authentication. You must make sure that the www.contoso.com Web application is configured for claims-based authentication. The main tasks for this exercise are as follows: 1. 2. 3. 4. Delete the internet.contoso.com Web application. Create a new Web application and configure it to allow anonymous access and to use claims-based authentication. Set the anonymous policy for the SharePoint Internet Web application and set anonymous access for the site collection. Test anonymous access to www.contoso.com.
6-38
Task 1: Delete the internet.contoso.com Web application

In SharePoint 2010 Central Administration, delete the SharePoint Internet Web application. Do not delete the application pool or database associated with the Web application.
Task 2: Create a new Web application and configure it to allow

anonymous access and to use claims-based authentication
In SharePoint 2010 Central Administration, create a new Web application by using the information in the following table.
Option Authentication IIS Web Site Value Claims Based Authentication Use an existing IIS Web site SharePoint Internet Allow Anonymous Yes Use existing application pool SharePoint www.contoso.com80-2 (CONTOSO\sp-farm) Content_www
Security Configuration
Application Pool
Database Name
Task 3: Set the anonymous policy for the SharePoint Internet Web
application and set anonymous access for the site collection
1. In SharePoint 2010 Central Administration, ensure that the anonymous policy for the SharePoint Internet Web application uses the settings in the following table.
Option Zones Permissions Value All zones None No policy
2.
In Windows Internet Explorer, on a new tab, go to http://www.contoso.com.
6-39
3. 4.
Sign in as CONTOSO\sp-farm with the password Pa$$w0rd. Configure the site permissions for Adventure Works to allow anonymous access to the entire Web site.
Task 4: Test anonymous access to www.contoso.com

1. 2. 3. 4. Go to the Contoso home page and sign out. Close Internet Explorer. Open a new instance of Internet Explorer, and then go to http://www.contoso.com. To verify that you are accessing this page anonymously, note that Sign In appears on the Adventure Works home page.
6-40
Review Questions
1. 2. 3. What is the importance of claims-based authentication? When would you use NTLM authentication? When would you incorporate multi-mode authentication into your authentication plan?
Best Practices Related to Authentication

Supplement or modify the following best practices for your own work situations: Consider your authentication sources; the authentication source will help you to determine which authentication method to use.
6-41
Determine whether to use classic mode or claims-based authentication. Identifying your authentication sources will help you to make this decision; some authentication methods are supported only by claims-based authentication. Consider any pass through authentication. Use the Secure Store Service or Kerberos authentication to avoid the double-hop scenario, where a Web server must authenticate to another service on behalf of the user.
Planning Managed Metadata
7-1
Module 7
Contents:
Lesson 1: Metadata in SharePoint 2010 Lesson 2: Overview of Content Types Lesson 3: Mapping Managed Metadata to Business Requirements Lab: Planning Managed Metadata 7-4 7-16 7-26 7-36
7-2
Module Overview
When you add metadata to items or documents, you can categorize or classify items to provide additional context, or filter items to find relevant material more easily. You can also search on metadata values or use metadata to refine search results. In this way metadata can improve search usefulness and relevancy and provide additional context for items such as documents. In most organizations, the most effective way to implement metadata is through a defined taxonomy that you have standardized through stakeholder input. This enables users to select metadata terms from a predefined list, which provides standard results. Microsoft SharePoint 2010 also has the capability to further enhance the application of metadata by using content types. Organizations can use content types to standardize specific types of file, document, or list item and include metadata requirements, document templates, retention settings, and workflow directly.
7-3
Objectives
After completing this module, you will be able to: Describe the function of managed metadata in SharePoint 2010. Describe the function of content types and explain how to apply them to business requirements. Match the managed metadata architecture in SharePoint 2010 to business requirements.
7-4
Lesson 1
Metadata in SharePoint 2010
To understand how SharePoint 2010 can deliver improvements in organizing data, you must understand the purpose of metadata and the taxonomies that you can use to standardize the management of metadata. You must also understand how to use the Managed Metadata Service in SharePoint 2010 to implement these taxonomies. In addition, it is important to know how farm topology affects the Managed Metadata Service, because many organizations will want to create taxonomies that all teams and all users can use. Conversely, you may want to create a taxonomy only for certain groups or users.
Objectives
After completing this lesson, you will be able to: Identify valid taxonomy structures. Identify options for managed metadata. Identify elements in the term store.
7-5
Identify the capabilities of the Managed Metadata Service. Plan for managed metadata in a multiple-farm environment.
7-6
What Are Taxonomies?
Key Points
Within SharePoint 2010, an organizational taxonomy is a classification mechanism, typically hierarchical in nature, which users within that organization can apply to documents or items that are held in SharePoint libraries or lists. The purpose of implementing a taxonomy is to provide a means to organize and classify stored content. Taxonomies can help users with the following tasks: Identifying how to store information. Identifying where to find information. Identifying the intended audience of information. Identifying the purpose of information.
When you plan a taxonomy, you must consider how and why users may want to classify or organize content.
7-7
Common taxonomies include the following sample classifications: Geography, such as country, region, office location, or site. Confidentiality, such as public, private, confidential, or secret. Departments, such as Human Resources, IT, Manufacturing, or Logistics. Projects or programs. External taxonomies such as vendors or customers.
Note: It is important to engage stakeholder inputsuch as getting input from user teamsto establish the classification and taxonomy requirements of different teams. Consider holding stakeholder meetings to help identify these requirements.
Although you should plan a starting taxonomy and nominate individuals to control the taxonomy, you should recognize that taxonomy structures are often organicthat is, the structure may develop and change over time, with new elements added and other elements removed. Using SharePoint 2010, organizations also have the capability to create folksonomies. A folksonomy is a more flexible way of organizing or categorizing content, which users can extend without administrator intervention. Question: Why is stakeholder input important to help establish the taxonomy?
7-8
What Is Managed Metadata?
Key Points
Metadata is information about files or documents. For example, metadata for a document may include the author of a document or the date that the document was last changed. In SharePoint 2010, you can manage metadata in a variety of ways and standardize your metadata across separate sites, site collections, Web applications, and farms to create taxonomies or folksonomies that help users to identify and use content more efficiently. Metadata can provide the following benefits: You can use metadata to provide additional references or context to an item or file, and users do not need to open the item to see this information. You can use metadata to categorize information. This categorization can help with filtering views and displaying relevant information. You can search for metadata or keywords. Metadata is indexed and searchable, and you can use the search results page to filter search results by metadata values.
7-9
Users can tag items by using enterprise keywords to assist with search. Enterprise keywords are stored as a single, flat list of keywords that all users can use and usually all users can update. Enterprise keywords can provide a folksonomy for content within an organization. You can provide for more controlled metadata usage by using terms. Terms are flat or hierarchical lists of text entries that you can use as metadata in SharePoint columns. For example, you can use terms to create categories or classifications for documents. Terms are often closed so that only specified users can update the list, providing a controlled taxonomy.
Note: You must distinguish between terms and keywords. Administrators typically predefine terms, whereas keywords are often not predefined. Administrators can promote keywords to terms by using the term store management tool.
You can create content types to represent specific types of file or document, such as a project proposal or a business process document. Content types can have a specific document template in addition to a set of defined columns for metadata. You can create content types within a site collection for use only in the same site collection, or publish the site collection as a content type hub so that you can use the content types in many site collections.
Additional Reading
For more information about managed metadata in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200885&clcid=0x409.
7-10
Introducing Terms and Term Sets
Key Points
SharePoint 2010 provides managed metadata in the form of terms, term sets, term groups, and term set owners. The following list explains this terminology: Term. A term is the individual value or entry that you want to provide to users for use as metadata. For example, a term may be an individual office location or an individual identification code for a project. Term set. A term set is a list of related terms. For example, a term set may be a list of all of the companys office locations or a list of all project identification codes. Term sets may be a flat list or a hierarchical list. You can use a term set as the target for a managed metadata column type. Term group. A term group is a collection of term sets that provides a set of access permissions. You plan term groups based on the users who must be able to update, change, or deprecate terms in term sets.
7-11
Term group manager. A term group manager is able to make changes to the term set, such as adding new terms, deprecating terms, or changing permissions for other users on the term set. Contributor. A contributor is able to make changes to terms and term sets within a term group, but cannot change permissions on the term group.
Note: Term sets also have a user known as a term set owner. Term set owners do not have any specific permissions on a term set, but are listed as a contact for query or reference purposes.
Deprecating a term takes that term out of service, but does not remove it from any items where that term is already applied. SharePoint 2010 stores terms, term sets, and term groups in the term store. There is one term store for each instance of the Managed Metadata Service.
7-12
What Is the Managed Metadata Service Application?
Key Points
The Managed Metadata Service application performs two primary functions: It stores enterprise keywords and term groups. The Managed Metadata Service holds managed keywords and term groups, term sets, and terms in a database that is associated with the service instance. It publishes content types. You can publish content types from a content type hub through the Managed Metadata Service. Each instance of the Managed Metadata Service supports one content type hub.
Each instance of the Managed Metadata Service supports up to 1,000 term sets and 30,000 terms for each term set, although maximizing both values in one instance is not supported. You can create several instances of the Managed Metadata Service in a single farm to separate metadata publishing, to publish more than one content type hub, or to scale beyond 1,000 term sets. You can also consume or publish metadata among different farms if metadata requirements overlap.
7-13
In each term group, you can specify users who have administrative permissions or the ability to update terms to enable specific users to govern term sets and control their application. Question: How can a large organization provide more than 1,000 term sets to users to support metadata requirements?
7-14
Consuming Managed Metadata Across Farms
Key Points
To provide enterprise scalability in SharePoint 2010, you can share metadata and content types between separate SharePoint farms by publishing the Managed Metadata Service. Consider an environment with multiple farms, such as a core intranet farm that services much of the organization, and a departmental farm such as a farm for research and development. The core intranet farm Managed Metadata Service includes term sets for company departments, office locations, product listings, and customers. It publishes several content types such as policy documents, manufacturing procedures, and project documents. The research and development farm Managed Metadata Service has a term set for project codes and risk categories. You can publish the term sets and content types from the core intranet farm for use in the research and development farm so that the company department terms, or project document content types, are available to sites in the research and development farm. In addition, the research and development farm can create additional term sets or content types without affecting the core intranet farm.
7-15
It is also possible to share managed metadata in two directions. In this scenario, the core intranet farm can also use term sets from the research and development farm, such as project codes. Question: Can more than two farms share term sets or content types through publishing the Managed Metadata Service?
7-16
Lesson 2
Overview of Content Types
Organizations can use content types to streamline working practices in SharePoint 2010. This approach works well because you can create templates for specific types of file, document, or item and include metadata with the content type. In this way, you can reuse a content type at numerous sites, lists, or libraries in the SharePoint hierarchy, and the content type becomes a standard reference for the type of information that you store. Many organizations have standard documents or standard information requirements that are frequently repeated. Content types enable organizations to specify and control the standards that are associated with this information.
7-17
Objectives
After completing this lesson, you will be able to: Identify the purpose of custom columns and site columns. Identify the purpose of information management policies. Identify the purpose of content types. Create and publish a content type hub.
7-18
What Are Custom Columns and Site Columns?
Key Points
In SharePoint 2010, you can create custom columns to hold information such as metadata or item data. Using custom columns, you can choose the data type for the column and specify the information that the column stores. Column data types include: Text or HTML content. A predefined list of choices, or choices that are based on another list in the site. Numbers. Currency values. Date and time entries. A person or group that is selected from the available SharePoint 2010 or Active Directory directory service users. An image. A calculation that is based on other column values.
7-19
A choice from a term set.
You can create columns in a specific list or library, but these columns are only available to items in that list or library, and you cannot use them with other lists or libraries.
Note: A SharePoint library is a specialized form of SharePoint list that stores documenttype data rather than metadata-based items. Libraries support metadata.
You can also create site columns, which can then be associated with any list or library at or below that site within the same site collection. Creating the site column at the root of the site collection means that the column can be used anywhere within the site collection. You must use site columns when you add metadata properties to content types.
Note: When you plan custom columns, plan to avoid using the same column name twice to clearly establish metadata and column associations.
Question: If you require a list of departments for users to apply as metadata in several different sites, how can you create the departments list?
7-20
What Are Information Management Policies?
Key Points
Information management policies enable you to specify settings for document or item behavior. The following table describes these settings.
Setting Retention Description Retention settings control how long the list or library holds an item and what happens after the item exceeds the retention period. You can specify the retention period in days, months, or years. The actions that you can specify include: Deleting to the Recycle Bin or permanently. Starting a workflow. Moving to another location. Deleting previous drafts or versions.
In addition, you can add a number of stages to the retention settings so that you can configure more complex management policies.
7-21
Setting Auditing
Description You can enable audit settings to track access to items in a list or library. The actions that you can audit include: Opening, viewing, or downloading items. Editing items. Performing a check-out or check-in. Moving or copying items. Deleting or restoring items.
Barcodes
This option assigns and optionally inserts barcodes into documents or items. Using barcodes can assist with electronic tagging and tracking of printed documents. You can use the labels function to add labels to documents. Labels can print the metadata that is associated with a document along with headings, such as confidentiality or the intended audience. You can prompt users to insert the label into the document when they use Microsoft Office applications.
Labels
You can configure information management policies on an individual list or library, or you can configure information management policies to apply to a content type. When you apply policies to a content type, you can, for example, ensure that all documents of that content type, such as a project document, are retained for seven years and then archived to an alternate location. Question: What is the limitation of specifying information management policies with a document library instead of a content type?
7-22
What Are Content Types?
Key Points
Content types are a powerful method for creating content of a certain type and associating columns, metadata, document templates, information management policies, or workflows with that type of item. For example, an organization may perform many projects. Each project requires a specific business case for that project. The organization already has a template that project managers can complete, but the organization wants to streamline processes and determine who is updating the business case document. In this example, you can create a business case content type. The content type will include the document template, and you can include any metadata requirements as custom columns, such as listing the project code and project manager. You can implement auditing for the business case through an information management policy in the content type, and you can attach a workflow to the content type for review and notification purposes.
Note: Content types are reusable at the site where you create them and lower in the site hierarchy, because subsites inherit site columns and content types.
7-23
If you use a content type in this way, you only need to create that content type once. Any site that adds that content type will include all of the inherent functionality of that content type, including the template, metadata, policy, and workflow functionality. This example shows that organizations can model the information that they store around content types to standardize associated requirements and reuse templates, policies, or workflows.
Note: You can apply content types to lists in addition to libraries. For example, you can create an employee vacation list where users create a new request for vacation by using a vacation request content type with the required columns. However, you cannot apply library-type content types to lists, nor can you apply list-type content types to libraries.
Content Type Inheritance

All content types that you create must have a parent content type. The parent content type governs whether the content type that you create is a list or library content type. In addition, the child content type will inherit columns and other settings from the parent content type. Content type inheritance can assist you in creating more refined versions of content types. For example, in the Business Case example, the organization may categorize projects as large, medium, and small projects. Large projects have additional management requirements for the business case, including a different template and additional sponsor requirements. In this case, you could create a Business Case (Large Project) content type, and use the Business Case content type as the parent. The new content type would inherit the settings of the parent, so you would only have to upload a new template document and add the additional sponsor as metadata for the new content type. Planning your content types ensures that you can identify common requirements, and use content type inheritance to save additional configuration tasks.
Planning Content Types

When you plan content types, it is important to ensure that you include all required content types that the organization uses. You must also identify any metadata (columns or term sets), retention, auditing, barcode, label, or workflow requirements for each content type that you establish. As part of a SharePoint 2010 implementation, you must involve the necessary stakeholders (end-user teams or departments) when you create your planned content types.
7-24
Content Type Publishing in SharePoint 2010
Key Points
In SharePoint 2010, content types that you create in one site collection are restricted to use within that site collectionby default, content types are not reusable across different site collections. To provide content types that can standardize items or documents across a whole organization with more than one site collection, you must use the Managed Metadata Service to publish content types. The Managed Metadata Service can publish content types from a single site collection that you configure, known as a content type hub. Any Web applications that consume the Managed Metadata Service can use the published content types in site collections and sites. You can only specify one content type hub for each instance of the Managed Metadata Service.
Note: Content types are reusable at the site where you create them and lower in the hierarchy.
7-25
To publish content types, use the following steps: 1. Create (or choose) the site collection that you will use for publishing content types. This is the content type hub. You must create all content types that you want to publish in this site collection. In the properties of the Managed Metadata Service, enter the URL of the site collection that will be the content type hub. In the connection properties of the Managed Metadata Service, ensure that the connection consumes content types from the content type gallery at the specified URL. Create the content types in the content type hub. Publish the content types at the content type hub. The published content types will become available after the Content Type Hub and Content Type Subscriber timer jobs have run.
2.
3. 4.
If you make changes to a content type in the content type hub, you will need to republish the content type for your changes to propagate. Similarly, if you no longer want your content type to be available, you can unpublish. However, unpublishing will not remove the content type from a subscriber site if that content type is already in use.
Note: You can speed up the publishing mechanism by forcing the Content Type Hub and Content Type Subscriber timer jobs to run before the scheduled time.
Question: How can you publish content types from two different site collections to all of the Web applications in a farm?
7-26
Lesson 3
Mapping Managed Metadata to Business Requirements
To implement taxonomies or content types smoothly in SharePoint 2010, you must establish the metadata requirements for different users and teams in your organization. If you do not plan this correctly, you may create complicated taxonomies that users do not understand and consequently do not use. To establish these metadata requirements, you should usually involve the information workers who are the end users of the solution. These workers will have important understanding and insight into the way in which metadata or content types can help a team or department. You can also appoint nontechnical users to control the managed metadata terms and content types that are published to the organization. This enables the people with the correct insight to administer important parts of the taxonomy.
7-27
Objectives
After completing this lesson, you will be able to: Plan for terms and term sets. Plan the import of managed metadata. Plan for shared taxonomies or content types. Plan for multilingual managed metadata.
7-28
Planning for Terms and Term Sets
Key Points
It is important to recognize that you may not be able to plan all term sets that users will use at the start of the deployment. Part of the planning process involves identifying terms that users will apply to items or documents. However, some useful term sets may not be apparent at the planning stage, and users may only identify additional term set requirements after you deploy SharePoint 2010. This is common behavior. In addition, in most cases, requirements for managed metadata will naturally change over time. Administrators will withdraw some terms and term sets and add other term sets to the taxonomy. The following table outlines the steps that you must perform to plan for term sets and term groups.
7-29
Step Identify any term sets that the organization requires
Description To establish term sets, examine the way in which the organization currently categorizes items or documents. Any text or choice metadata fields that apply to several sites or site collections are good candidates for term sets, particularly if you wish users to select values from a predefined list. Any predefined selections for filtering views or search and any values that users may use to tag items are also potential term sets. Not all metadata should be managed metadatacolumns with yes/no values or different values in each location where you use them are better as list, library, or site columns.
Identify appropriate term groups
To establish term set groups, investigate who should be using or controlling the term sets in the organization. Term sets form a security boundary, controlling who can see or define term sets in the term group. You may form term groups based on organizational structure, such as a department or subsidiary organization that controls a number of term sets. In multi-tenancy environments, you typically create a term group for each hosted organization. For each term group, identify at least one group manager who can change and control term sets and terms. At least one term group manager should typically not be a member of the IT department or the SharePoint 2010 support team. The term group manager should be someone who understands the purpose and application of the term sets within the term group. Also, identify users who can fulfill the contributor role. Contributors can make changes to term sets and terms, but cannot alter role memberships.
Identify the appropriate term group managers and contributors
Define the term groups and term sets
To define the term groups, create the term group within the Managed Metadata Service, and then specify the group managers or contributors for the term groups. Group managers or contributors can then create or import the term sets and terms.
Note: You can specify a term set owner for each term set. This is not an administrative role with permissions. It is solely used for contact information in relation to the term set. It is recommended that you specify a user in an appropriate group manager or contributor role as a term set owner.
7-30
Planning to Import Managed Metadata
Key Points
An important first step in importing managed metadata is to identify any existing sources of terms. These sources may include: Any forms that are currently in use. A previously defined (or partially defined) taxonomy. Any existing Microsoft Office SharePoint Server choice columns. Any well-known hierarchies such as folder structures or departments.
You can create terms individually in a term set by using the Term Store Management Tool Web interface. However, for large term sets or term sets with a deep hierarchy, this can be a time-consuming task. You can also create term sets by importing the terms and hierarchy from a comma-separated value (CSV) file. After you identify a term set requirement, you can create an import file for the term set as a CSV file with the following columns:
7-31
Term set name Term set description LCID (locale identifier) Available for tagging (true/false) Term description Level 1 term Level 2 term Level 3 term Level 4 term Level 5 term Level 6 term Level 7 term
Note: The Term Store Management Tool provides a sample CSV import file.
You are recommended to create a planning worksheet that identifies any term set requirements by using these columns. You can then use the planning worksheet to import the term set into SharePoint 2010. You can use Microsoft Excel to facilitate this import process. Question: Who can import term sets?
Additional Reading
For more information about the managed metadata input file format in SharePoint Server 2010, see http://go.microsoft.com/fwlink/?LinkID=200886&clcid=0x409.
7-32
Planning for Shared Taxonomies and Content Types
Key Points
In most SharePoint 2010 environments, you only require a single instance of the Managed Metadata Service. When you plan for a single instance of the Managed Metadata Service, consider the following points: You can implement any term sets that you require in the single instance of the Managed Metadata Service, up to 1,000 term sets. You can implement enterprise keywords from the single instance of the Managed Metadata Service. You can publish content types from a single site collection only.
If you are planning for multiple instances of the Managed Metadata Service and you plan to share instances across Web applications, consider the following best practices: Only configure one Managed Metadata Service instance to be the default storage location for column-specific term sets.
7-33
Only configure one Managed Metadata Service to be the default storage location for keywords.
If you are planning the Managed Metadata Service to support a multi-tenancy environment, consider the following: Term set groups can define which users can read and use terms in the term group. This enables a single term store to support term sets for many site collections, where each site collection may be a different hosted organization. Content type publishing is associated with the Managed Metadata Service connection to the Web application object. This means that you may require multiple Web applications to support separation of organization-based content types. This is only a requirement if one hosted organization requires multiple site collections.
7-34
Planning for Multilingual Managed Metadata
Key Points
SharePoint 2010 can represent a term in the term store with a number of different labels. You will most commonly see different labels for the same term if you implement synonyms for terms in the term store. For example, the term human resources may also have the synonym personnel. In this example, SharePoint 2010 treats human resources and personnel as labels for the same term. In a similar way, SharePoint 2010 can treat different language versions of a word as being different labels for the same term. This enables you to define the term set once, but apply the term set in as many supported languages as you require, without needing a separate term set for each language. To implement multilingual term sets, you must perform the following actions: 1. 2. Install the SharePoint Server 2010 language pack for each language that you require. Use the Term Store Management Tool to add each language to the list of working languages for the term store.
7-35
3.
Select one language to be the default language for the term store.
You can use the Term Store Management Tool to enter multiple labels in each language; for example, you can enter synonyms of the terms in each language. However, each language must have a default label. SharePoint will display the term by using the default language and label regardless of the language that you use to enter the term.
Note: If your SharePoint environment includes multiple term stores, consider updating all term stores to support the same languages.
Additional Reading
For more information about multilingual term sets in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200887&clcid=0x409.
7-36
Lab: Planning Managed Metadata
Exercise 1: Designing Content Types and a Term Set Framework

Scenario
Contoso, Ltd would like to make use of centrally managed document templates and a standardized taxonomy. This will enable users to tag and locate information based on a consistent set of terms. Your team must design and implement a central SharePoint 2010 term store and a content type hub. The information that your team needs is detailed in the supporting information. Use these documents to produce your term set design. The main tasks for this exercise are as follows: 1. 2. Read the supporting information. Complete the Managed Metadata Planning worksheet.
7-37

1. 2. 3. Read the lab scenario. Log on to 10231A-NYC-DC1-07 as CONTOSO\Ed with the password Pa$$w0rd. In the E:\Labfiles\Lab07\Starter folder, read the information in the Managed Metadata Requirements.docx file.
Task 2: Complete the Managed Metadata Planning worksheet

1. 2. 3. In the E:\Labfiles\Lab07\Starter folder, open the MMS Planning Worksheet.xlsx file. On the Services sheet, fill in the details for all of the term groups that you require. On the Content Types sheet, fill in the details for any content types that you require.
Exercise 2: Creating the Managed Metadata Service Application

Scenario
After planning the managed metadata requirements, you have been tasked with creating a proof of concept to demonstrate to the Marketing department how they can tag brochures. You should create the Managed Metadata Service application for the proof of concept. The main tasks for this exercise are as follows: 1. 2. 3. Create a site collection called CTHub on intranet.contoso.com. Create a new Managed Metadata Service application to publish the CTHub site collection as the content type hub. Verify that the Content Type Syndication Hub feature is active.
Task 1: Create a site collection called CTHub on intranet.contoso.com

Use Central Administration to create a new site collection with the following settings:
7-38
Title: CTHub Description: Contoso Content Type Hub URL: sites/cthub Template: Team Site Primary Site Collection Administrator: ed Accept defaults for all other settings.
Task 2: Create a new Managed Metadata Service application to publish

the CTHub site collection as the content type hub
1. 2. Use Central Administration to start the Managed Metadata Web Service on NYC-DC1. In Central Administration, create a new Managed Metadata Service application with the following settings: Name: Managed Metadata Service Application Database name: TermStore_Default Application pool: SharePoint Web Services Default Content type hub: http://intranet.contoso.com/sites/cthub
Task 3: Verify that the Content Type Syndication Hub feature is active
1. 2. 3. Navigate to the CTHub site collection. Verify that the Content Type Syndication Hub site collection feature is active. Activate the Content Type Syndication Hub site collection feature if required.
Exercise 3: Importing Term Sets

Scenario
After creating the Managed Metadata Service application, you should import the term sets that the Marketing department requires. The main tasks for this exercise are as follows: 1. Create a new term set group called Contoso
7-39
2.
Import the Cost Center and Department term files.
Task 1: Create a new term set group called Contoso

Open the Term Store Management Tool for the Managed Metadata Service application, and then create a new group with the following settings: Name: Contoso Description: Contoso Terms
Task 2: Import the Cost Center and Department term files

1. 2. Import the Contoso Sample Terms for Import Cost Center.csv file from the E:\Labfiles\Lab07\Starter folder. Import the Contoso Sample Terms for Import Department.csv file from the E:\Labfiles\Lab07\Starter folder.
Exercise 4: Publishing a Content Type

Scenario
You should create and publish a new content type for inclusion with the proof of concept to the Marketing department. The main tasks for this exercise are as follows: 1. 2. 3. 4. 5. Create a new site collection called Marketing. Create a custom content type in the CTHub site collection. Publish the custom content type. Run timer jobs manually. Verify that the custom content type is available in the Marketing site.
Task 1: Create a new site collection called Marketing

Use Central Administration to create a new site collection with the following settings: Title: Marketing
7-40
URL: marketing Primary Site Collection Administrator: ed Accept defaults for all other settings.
Task 2: Create a custom content type in the CTHub site collection

Go to the http://intranet.contoso.com/sites/cthub site collection, and then create a new content type with the following settings: Name: Marketing Document Description: Marketing Document Parent Content Type: Document Create a new content type group called Contoso. Accept defaults for all other settings.
Task 3: Publish the custom content type

Publish the Marketing Document content type.
Task 4: Run timer jobs manually

1. 2. Use Central Administration to run the Content Type Hub timer job immediately. Use Central Administration to run the Content Type Subscriber SharePoint 80 timer job immediately.
Task 5: Verify that the custom content type is available in the

Marketing site
1. Go to the http://intranet.contoso.com/sites/marketing site collection, and then view the Content type publishing settings for the site collection. You should see Marketing Document listed as a subscribed content type. In the Shared Documents library, add the Marketing Document content type, and then verify that users can create new Marketing documents.
2.
7-41
Review Questions
1. 2. 3. 4. 5. Can the term set owner perform any changes to the term set? What is the difference between a term set and enterprise keywords? Can you implement more than one instance of the Managed Metadata Service in a single-farm environment? Does every SharePoint farm require a unique Managed Metadata Service? Can you use a content type from one site collection in another site collection without using a content type hub?
Best Practices Related to Planning Managed Metadata

Supplement or modify the following best practices for your own work situations: Involve stakeholders such as information workers or team leaders in identifying metadata requirements.
7-42
Identify nontechnical users who can act in the group manager or contributor role to manage term sets. Configure only one Managed Metadata Service as the default store for term sets and keywords for each consuming Web application.
Planning Social Computing
8-1
Module 8
Contents:
Lesson 1: Overview of Social Computing 8-3 Lesson 2: Planning for Social Computing Functionality in SharePoint 2010 8-14 Lesson 3: Planning for the User Profile Service Lab: Planning Social Computing 8-37 8-54
8-2
Module Overview
Organizations are increasingly distributed, with employees working in different locations, time zones, and cultures. In this distributed model, people with the expertise that you require can be difficult to find. In addition, the organization can lack a sense of community. Social computing enables an organization to find people, expertise, and information. It provides multiple platforms for users to publish content, such as My Site Web sites, wikis, and blogs, and makes this process engaging. You can implement social computing to help your organization to foster a sense of community and loyalty even amongst a distributed workforce.
Objectives
After completing this module, you will be able to: Describe the social computing functionality that is available in Microsoft SharePoint 2010. Describe how the social computing functionality in SharePoint 2010 meets business needs. Plan user profiles for providing social computing functionality.
8-3
Lesson 1
Overview of Social Computing
Social computing enables you to find the knowledge that you already have in your organization. To understand how to access this knowledge, you must be able to define how social computing will benefit your organization and identify the features that will best fit your business requirements. You must be prepared to tackle concerns about privacy. You must also plan how to facilitate collaboration amongst your users.
Objectives
After completing this lesson, you will be able to: Explain the business goals and benefits of social computing. Describe social computing features in SharePoint 2010. Explain why planning for social computing must include privacy considerations. Describe how to plan for collaboration among users.
8-4
Business Goals and Benefits
Key Points
The past decade has seen a dramatic shift in the way in which people communicate, both inside and outside their working environments. Blogs, wikis, social networks, and other activities that engage people in communication via the Internet have fundamentally transformed the way in which people manage both personal and professional relationships. The term social computing describes the combination of features and functionality that supports these activities. Forward-thinking organizations are looking for ways to implement social computing in a controlled manner. What benefits do they hope to gain?
Benefits of Social Computing

Social computing capabilities are critical in a global business. Social networks encourage people to contribute their personal knowledge and experience to a searchable pool. Social computing technology can facilitate conversations across time and distance for complex organizations that are distributed across geographic, national, and time zone borders. Social computing can foster a feeling of community and preserve the individual voice in spontaneous, unstructured
8-5
communication. This builds the social capital that all businesses require to operate effectively. In addition to these generalized benefits, social computing supports strategic business goals and scenarios, including the following: It provides ways to capture and share tacit knowledge. This is critical to the continuity and competitiveness of businesses that are faced with losing key knowledge through the retirement of staff and the virtualization of organizations through outsourcing and remote working. It enables people to find and engage experts inside and outside the organization. This helps to generate ideas and facilitate the conversations that lead to rapid innovation. It helps organizations to attract and retain young talent. It provides people with a familiar infrastructure of collaborative and social media that they can use to blend work and life priorities effectively and be productive. It increases organizational productivity. It provides managers with clear vision into team dynamics and gives knowledge workers easy, natural ways to share insights and collaborate.
Ensuring the Success of Social Computing

The success of social computing depends on adoption and use as much as the underlying technology. Well-designed social applications that become selfsustaining tend to have the following characteristics: They are easy to learn and use. They enable people to discover one another and form their own communities. They reward people with recognition for creating and discussing content. They enable people to customize how they represent themselves and how they interact with the network. They engage people across multiple channels, devices, and media types for rich conversations. They are self-regulating but have well-defined guidelines to prevent abuse.
8-6
Social Computing Features
Key Points
SharePoint 2010 builds upon the social computing features of Microsoft Office SharePoint Server 2007 and provides a rich multimedia environment for bringing knowledge and expertise to the fore throughout the organization. The social computing features in SharePoint 2010 include: User profiles My Site Web sites Social feedback Wikis Blogs
8-7
User Profiles
The user profile is the cornerstone of many of the social computing features. User profiles consist of information about the user. This information ranges from name and contact details through to subjects of expertise, projects worked on, and other valuable information. The profile is constructed from data that is imported from directory services such as the Active Directory directory service. You can augment it from other business systems, or users can manually update it.
My Site Web Sites

The My Site Web site is the personal site of the user. The My Site Web site is fully customizable, providing a space for users to define their identities as they want them to be presented and share whatever information they see fit. My Site Web sites display the users profile information and provide a hub for many other social computing features. My Site features include: My Site Web site. The users My Site Web site provides a central point for a user to store and access information. Profiles. The users profile is used to populate the My Site Web site with information about a user. Search services and other features can access this information. Newsfeeds. The users activities can be displayed on his or her My Site Web site. Organization Browser. This tool displays the organizational hierarchy.
Social Feedback
Social feedback provides a way of making commonly required data easily accessible through the social computing space. Social feedback mechanisms include tags, bookmarklets, the note board, and ratings.
Wikis
SharePoint 2010 incorporates advanced wiki capabilities, including the wiki. Wikis can contain rich multimedia files, such as music and videos, directly via a Media Web Part. This enables a wiki to provide a rich multimedia experience for the user, which is very compelling.
Blogs
Users and groups can use and maintain blogs, which SharePoint 2010 supports and manages.
8-8
Question: How is a wiki different from a blog?
8-9
Privacy Considerations
Key Points
Privacy is a key planning point for organizations that intend to deploy social computing features. Users may have concerns that their personal data will be shared outside the organization or shared with inappropriate groups in the organization. SharePoint 2010 provides tools to help maintain the privacy of information in your social computing environment. Your approach to social computing must balance the availability of personal information and privacy. SharePoint 2010 provides personal and enterprise-level security settings that govern access to and visibility of data. Site owners, including My Site owners, can perform the following tasks: Grant permissions for readers, editors, and content managers. Grant or revoke access to sites individually or by group or organizational role. Open and close comment threads. Enable or disable content ratings. Make only certain content viewable.
8-10
Enact other fine-grained controls to ensure that information does not spread further than policy permits.
In terms of content, individuals must determine what they feel is appropriate to share and what is not. You can help them by providing firm guidelines that apply to the nature of the content that they post. Enforcing these guidelines is a matter of management, education, and trainingnot technology. The information in the user profile that is displayed on the users My Site Web site is accessible to search services. It is also exposed in tags, notes, ratings, and the users activity feed. Your social computing plan should include how to assess the requirement for privacy and how to protect information. You should use SharePoint policies, which help you to maintain the privacy of information that you store in the user profile.
8-11
Planning for Collaboration
Key Points
Collaboration sites store information that individuals and groups can collectively author, share, and modify. Collaboration sites may be associated with a particular portal site collection or part of a publishing collection. However, they can also be stand-alone sites for specific projects, teams, or events. For example, you can create a collaboration site for members of a project team to share information, schedule meetings, and discuss the status of the project without publishing this information to the corporate intranet.
Planning the Number of Collaboration Sites

You can create collaboration sites for your users, or you can allow the users to create collaboration sites themselves. If you choose to restrict the number of people in the organization who can create collaboration sites, you can control the number of sites and plan for their storage and maintenance. If you choose to allow users to create collaboration sites themselves, you should plan for monitoring of the size, location, and activity levels of each site.
8-12
You should estimate how many collaboration sites to expect in your environment and decide how many of these sites you are willing to support.
Planning the Location of Collaboration Sites

When you plan the location of your collaboration sites, consider hosting them either on a separate Web application or in separate content databases in the same Web application as your portal or publishing site. This will give you more flexibility for data backup and maintenance. It will also give you easier recovery.
Planning Paths for Collaboration Sites

You can use specific paths to contain site collections, similar to the way in which folders contain files or documents in the file system. When you create a Web application, two paths are made available for you: Root path (/). The root path contains only one site collection. For example, if you want a URL to appear as http://company_name/default.aspx, you create the site collection at this root path. Sites path (/sites). The /sites path can contain many site collections. For example, when you use the /sites path, the URL for a site named Site_A would be similar to http://server_name/sites/Site_A/default.aspx.
You can also create additional paths, which enable you to group site collections. By defining managed paths, you can specify which paths in the URL namespace of a Web application are used for site collections. You can specify that one or more site collections exists at a specified path. This can be a convenient method of consolidating multiple site access for users in various departments. You can use an explicitly named path (for example, http://server/sites/team) for a single site collection. A wildcard path of "sites" (for example, http://server/sites/) indicates that child URLs of the path are site collections. This means that when you create a site collection, you have the following options: You can create the site collection at the root of the Web application. You can create the site collection under the /sites path. You can create the site collection under any additional paths that you have created for that Web application.
8-13
When you plan how to group collaboration sites, consider the following: For a complex infrastructure with many site collections, you can group similar sites together. For example, you can use /personal for individual user sites and /team for group collaboration sites, instead of using /sites for all. For an infrastructure that has external access to sites, you can add a filter to your firewall or router to constrain a specific namespace to internal access only. For example, you can expose the /team path but not the /personal path for external collaboration.
8-14
Lesson 2
Planning for Social Computing Functionality in SharePoint 2010
To create a plan for social computing in your organization, you must identify the social computing functionality that will meet the business requirements. You must be able to describe the key features of social computing, including My Site Web sites, social tagging, wikis, and blogs. You must be able to identify who will use these features and plan how to deploy and manage them. This will support the goal of enabling your users to locate people and expertise quickly.
Objectives
After completing this lesson, you will be able to: Map business requirements to social computing functionality. Describe My Site Web sites. Plan My Site Web sites. Describe social tagging.
8-15
Plan social tagging. Plan wikis. Plan blogs. Describe how to locate people and expertise.
8-16
Mapping Business Requirements to Social Computing Functionality
Key Points
When you plan for social computing, you must review the business requirements and determine which features you will deploy.
User Profiles
User profiles provide social computing features such as My Site Web sites and profile information. User profiles also expose user information to search services. Locating people and expertise is key in making knowledge available in the organization, which is a major driver for deploying social computing. When you plan user profiles, consider the following questions: Which profile properties are likely to be searched on? Which profile properties can you synchronize from directory services or business systems? Which synchronized profile properties will map to default properties?
8-17
If the required profile property does not map to a default property, will you create an additional property for it? Which properties should be available to the Search Service? Which user profile properties should be visible on the users My Site Web site?
My Site Web Sites

My Site Web sites are used in organizations that want to provide users with a personal space. When you plan My Site Web sites, consider the following questions: Does each user require a personal, customizable Web site? Should users be able to customize their My Site Web sites? Should users be able to view other users profiles? Should users be able to edit their own profile information?
Social Tagging
Social Tagging is a subset of Social Feedback. Business requirements that indicate the use of social tagging are primarily related to search. If your organization places a high value on users being able to locate people and expertise quickly, you should enable social tagging. When you plan social tagging, consider the following questions: Will you use social tagging? Should all users be able to add social tags?
Wikis
Wikis provide a central location for content to be published, commented on, and amended. When you plan wikis, consider the following questions: Is there a requirement for a central information store that could be implemented by using a wiki? Should all users be able to edit all wikis? Do you require media-rich wikis?
8-18
Blogs
Blogs provide a location for a user or group of users to publish information. Other users may comment on this information but not amend it. When you plan blogs, consider the following questions: Should all users be able to create their own blogs? Should all users be able to comment on all blogs? Do you require media-rich blogs?
8-19
What Are My Site Web Sites?
Key Points
Organizations provide users with their own personal sites by using My Site Web sites, which enable users to share information about themselves and their work. My Site Web sites provide a rich set of social networking and collaboration features that encourage users to publicize their areas of expertise, the projects that they are working on, and the relationships that they have with colleagues. Sharing this type of information encourages collaboration, builds and promotes expertise, and makes it easier for people to find relevant content. Understandably, people have concerns about the privacy of the information that they share. To help alleviate these concerns, you can plan for administrators to set policies to protect privacy. My Site Web sites include the following: A profile for each user where users can share their expertise, profile pictures, and other information. A newsfeed for tracking activities such as social tags, status updates, and comments by colleagues.
8-20
A tag and note tool that helps you conveniently tag or post notes on sites directly from a Web browser. A shared picture library, a shared document library, and a personal document library. Web Parts such as an RSS viewer for viewing RSS feeds from blogs, or other sources. An organization browser that uses Microsoft Silverlight 3 to provide a dynamic organizational browsing experience. A manageable list of colleagues.
Integrating User Profile Information

My Site Web sites rely on user profile synchronization, which enables you to integrate profile information that is stored in a directory service. SharePoint 2010 can synchronize user profiles with Active Directory Domain Services or business systems such as Siebel SharePoint 2010. My Site Web sites rely on user profile synchronization, so you must also plan the deployment of the User Profile Service. The User Profile Service stores information about users in a central location, and My Site Web sites use this information to enable users to collaborate efficiently. To provision My Site Web sites, enable social computing features such as social tagging and newsfeeds, and create and distribute profiles across multiple sites and farms, you must enable the User Profile Service. As a result of user profile synchronization, consistent and timely information is always available on a users My Site Web site. You can synchronize information about users across the deployment to all site collections that use the same User Profile Service application. Personalization features can also use this information to increase the value of collaboration and relationships in an organization. When you plan the synchronization of user profiles, you should include the following tasks: Start with the default properties of user profiles in SharePoint 2010. Identify connections to directory services that will provide supplemental information for properties of user profiles. Consider additional business data that enables you to connect users to line-ofbusiness (LOB) applications.
8-21
Question: What does the User Profile Synchronization Service provide for My Site Web sites?
8-22
Planning My Site Web Sites
Key Points
When you plan My Site Web sites, you must plan which My Site Web site features will be available to each user. You must answer the following questions to determine access to features: Who can create personal sites? Who can create social tags and notes? Who can add colleagues?
To ensure simplicity of management, you should plan to assign permissions to security groups only where necessary. The following table provides guidance for configuring permissions.
8-23
Permission Create Personal Site
Guidance
By default, all authenticated users can create a My Site Web site. Ensure that you want the default setting to apply to the organization. Alternatively, you can use one or more security groups to grant the Create Personal Site permission to a subset of users in an organization.
Use Social Features
By default, all authenticated users can add ratings and social tags to documents, to other Office SharePoint Server items, and to other items, such as external Web pages and blog posts. Users can also leave impromptu notes on profile pages of a My Site Web site or any Office SharePoint Server page. Alternatively, you can use one or more security groups to grant the Use Social Features permission to a subset of users in an organization. By default, all authenticated users can edit their profiles, add or edit colleagues, and add or edit memberships. Alternatively, you can use one or more security groups to grant the Use Personal Features permission to a subset of users in an organization.
Use Personal Features
The My Site Web sites that are created, the social tags and notes, the colleague lists, and other content that is used in a My Site Web site must be stored. In organizations that have large numbers of active My Site Web sites, storage management can become a major task for the SharePoint 2010 administrator. You can mitigate this potential problem by planning the storage and maintenance of My Site Web sites before you deploy them. You must plan how you will store the My Site Web sites and how you will manage, monitor, and maintain that storage.
How Are My Site Web Sites Hosted?

The My Site Host is a site collection that you use for hosting the profile and newsfeed parts of My Site Web sites. Content for My Site Web sites is hosted in its own site collection. My Site Host collections are not automatically created; an administrator of the User Profile Service application must create a My Site Host site collection before provisioning My Site Web sites. For optimal performance, you should create the My Site Host in a dedicated Web application. In geographically distributed SharePoint infrastructures, you can create multiple Web applications to host My Site Web sites and then use trusted My Site Host locations to target particular Web applications for specific groups of users.
8-24
Trusted My Site Host Locations

In organizations where multiple server farms are deployed or where multiple User Profile Service applications are configured, it is possible for users to create multiple My Site Web sites, although this may not be desirable. If your organization includes multiple farms or multiple User Profile Service applications that host My Site Web sites, you should consider whether to prevent users from creating multiple My Site Web sites. Using the Trusted My Site Host Locations feature can prevent users from creating multiple My Site Web sites. This feature enables you to specify trusted My Site locations, which enable users to be redirected to the My Site Web site that is intended for their user accounts, regardless of where they are browsing when they attempt to create a My Site Web site. This feature ensures that each user creates only one My Site Web site in the organization. You can manage Trusted My Site Host Locations by specifying target audiences for each location.
Geographically Distributed Deployments

In organizations that are widely dispersed geographically, planning for My Site Web sites must include considering the location of the users in the organization. Best practice is to target trusted My Site locations for groups of users based on their physical location, unless there is an overriding business requirement to do otherwise. Question: How can you use trusted My Site locations to help manage My Site Hosts?
8-25
What Is Social Tagging?
Key Points
Social tags are user-generated words or phrases that describe pieces of information according to a set of attributes or criteria. Tags make it easy to find and share information about a specific subject or task. Tags are not part of a formal taxonomy, such as the enterprise keywords in the term store that is associated with a Managed Metadata Service application; users create social tags based on their experience with a specific piece of information.
Social Tagging Features

SharePoint 2010 contains the following social tagging features: Social tags. These enable users to save items of interest, organize all information for a project, and connect to others who share their interests. Although tags themselves are public, you can choose to prevent others from seeing that you have tagged a specific item by marking that tag as private. The note board. This enables users to add comments about Web pages, documents, and library items to be tracked in a central location. Notes are always public.
8-26
Ratings. These are social tags that enable users to assess the value of content against a scale, for example, one through five stars. Bookmarklets. These enable users to add tags and notes to pages that are outside a SharePoint environment. For example, if users add tags to a page on an Internet Web site, these tags and notes can appear on the Tags and Notes tab of their My Site Web site.
The Use Social Features permission of the User Profile Service controls the ability to use social tags, the note board, and ratings. By default, all authenticated users can add social tags to documents and other SharePoint items, and anyone with the Manage Social Data permission can delete a tag. Tag clouds provide a view of the tags that a group of users have applied to a single piece of information. Frequently used tags are displayed in large, bold text; tags that are used less often appear in smaller text. By default, each users My Site Web site includes a tag cloud Web Part.
Benefits of Social Tagging

Organizations can benefit from the consistent use of social tagging. However, the information that social tagging provides is only useful if it is complete and consistently applied. When you design a plan for social computing in an enterprise, you must plan how to foster a culture of using the social computing features. The information that users receive when they click a tag or perform a search must be accurate and up to date. This is important; if users cannot trust the data, these features will cease to be valuable and will fall out of use. Fully utilized social tagging provides the following benefits: It improves collaboration and improves the discoverability of business information. It enables users to identify themselves and find experts. Note board comments can identify a group of users who are interested in a specific topic. Suggestions for a user's My Colleagues list can be derived from these social connections. It increases the visibility of high-quality content and identifies the latest version of content. For example, a My Site Web site feed can notify a user when a Web page is tagged with a tag that the user has included in his or her user profile.
8-27
Performance and Capacity

Your plan for social computing must include adequate storage for social tagging. Poor performance and capacity issues can discourage users from participating in social tagging activities. Social tags consist of a user identity, an item URL, and the tag itself. Social tags are stored in the social tagging database that is part of the User Profile Service. The terms that are used in tags are stored in a term store, which the Managed Metadata Service manages. The term store does not identify the person who created the tag or the Web page to which the tag was applied. Although individual tags, ratings, bookmarklets, and comments require very little storage space, cumulatively they affect the size of the profile database, the term store, and the social tag database. Given the rapid increase in adoption of social tagging, your implementation must be able to scale out to accommodate large numbers of new users. Question: Where are social tags stored?
8-28
Planning Social Tagging
Key Points
Planning social tagging requires consideration of the users privacy. You must ensure that appropriate safeguards are in place, to prevent the violation of a user's privacy or the exposure of content that should be kept secure. When you plan for social computing, you should consider setting user profile policies to help protect sensitive information. User profile policies help to protect privacy but also provide users with some discretion in their use of social features. In addition, administrators can help to safeguard sensitive content by excluding sites from social tagging. For example, an administrator can add a site URL to a list of excluded sites to prevent the site and any sub-sites from being tagged. Your plan for social computing must include user training and education about the security and privacy implications of social tagging features. For example, users must understand that when a site or document is tagged, the title and URL of that site or document is broadcast to anyone who lists that user as a colleague on their My Site Web site and anyone who has that tag listed as an interest in their user profile.
8-29
Viewing Social Tagging Information

There are three ways in which a user can see social tagging information: On a users My Profile page. As the result of following a tag or a colleague. On Web pages in the Office SharePoint Server farm.
Hiding Social Tagging Information

Three features of SharePoint 2010 help to protect privacy and security: Private tags. A user who adds a tag to a Web page can indicate that the tag is private. Other people cannot see the fact that the tag was added to the Web page, nor do they see the tag in the users tag cloud. The ratings control. The ratings control only displays the aggregate rating that an item has received. It does not identify the users who rated the item or display the individual ratings that were provided. Security trimming. Adding a tag, a note, or a rating to a Web page creates an activity. The SharePoint security trimmer determines whether a given user has permission to view a specific Web page by using permissions information that the Search Service gathers as it crawls Web pages. If the security trimmer cannot determine whether a user has permission to view a Web page, it reports that the user does not have permission to view the Web page. If the user is not permitted to view the Web page, SharePoint 2010 does not display the activity.
Note: If the Search Service has not crawled a Web page, activities that relate to that Web page are not displayed.
Best Practices
The following best practices will help you to develop a social tagging plan that makes effective use of the available features: Educate users about which aspects of their social tagging activity are public and which are private. Ensure that users understand when to mark tags as private.
8-30
Carefully evaluate all custom code before you deploy it. A custom application can access social tagging data by using the social tagging object model. An application can access the same social tagging data that is available to the account that it runs under. Consider a custom security trimmer. If users tag external Web sites, the SharePoint security trimmer always trims this information. If this behavior is not appropriate for your organization, you should consider implementing a custom security trimmer.
Question: How does SharePoint 2010 determine whether to display information about tagging activity for a Web page?
Additional Reading
For more information about how to plan policies for user profiles in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200889&clcid=0x409.
8-31
Planning Wikis
Key Points
If your organization requires a centralized knowledge repository, consider using a wiki. A wiki is designed to store and share information on an enterprise-wide scale, providing a publishing site for large volumes of information across an enterprise.
Planning a Wiki
Before you plan the implementation of a wiki, you must assess whether it is the most appropriate solution for the organization. A wiki provides a central location for multiple users to contribute to a knowledge repository. If you require one-tomany communication about a project or area of interest, you should consider using a team site.
Planning How to Implement a Wiki

When you decide how to implement a wiki, you should consider the following questions: What purpose will the wiki serve? A wiki should have a purpose. A wiki should meet a specific business requirement, providing a centralized body of
8-32
knowledge about a specific business problem. A wiki supports a virtual community that creates, changes, and removes content, including content that others create. If you require a more structured exchange of knowledge, and most communication will be one-to-many instead of the more freeform wiki behavior, you should consider using either a team site or a blog. How many users will contribute? Several factors will influence this decision. Will you be able to support increasing growth and a requirement for increased network and server capacity? Should you determine key contributors from each business area who will become the primary contributors? Are there legal considerations about who can contribute? Who has access to the wiki? In theory, all members of an organization can be granted access to contribute, edit, and update content in a wiki for the organization. If you must separate information by group, consider using either a team site or a blog. How much control over the content should you implement? A wiki is designed for informal contributions. You should create guidelines or requirements for creating specific kinds of content or content about a specific subject. You should also consider how to tackle inappropriate or inaccurate entries.
Planning a Location for Hosting a Wiki

A wiki is typically edited by a large number of users, although the storage requirement for the content is usually low. The planned storage location must therefore support increasing performance requirements and increasing capacity requirements. If your organization requires multiple collaboration sites, you must determine whether you will use wikis or team sites. Multiple wikis that are built on multiple site collections cannot communicate with one another. These wikis cannot share features such as in-line auto-completion, lists, and custom searching; these features cannot span multiple wiki instances. You should use multiple site collections only if you determine that multiple team sites are a more suitable solution for an organization, given size, location, and access considerations. However, you can create a wiki as a subsite of another site.
8-33
Planning Blogs
Key Points
Blogs enable individuals or teams to create content that is available for others to comment upon or add to, but not amend. Blogs are persistent; a user can see what was originally written and then read subsequent review comments. The majority of blogs contain static content in the form of articles and related comments. The owner of the blog can post a new entry or modify a previous entry. Uses of blogs include sharing work-related content through the expression of factual information, opinions, or ideas. Blogs may be formal or informal in style and tone.
Planning Blogs
When you plan blogs in your organization, you should consider who will be permitted to own a blog. Allowing each user to maintain a blog can be timeconsuming and not necessarily to the benefit of the organization. A proliferation of small, informal blogs that are not regularly maintained is not likely to make it easier to find information and expertise throughout the organization. You should consider limiting blogs to those who have a specific business requirement to disseminate information. You should also create guidelines about how formal or informal the blog can be and how often the owner should update it. Blogs that are
8-34
based on expertise are useful on a day-to-day basis. This may include, for example, the IT team blogging about a new project that affects the majority of users. At a more strategic level, an executive blog offers a unique opportunity for executives to communicate their thoughts about leadership in an organization and to invite feedback from the employees.
Storing Blogs
In terms of storing content, most blogs are relatively small, although this depends on the style of the blog. A text-based blog will take up much less space than one that uses multimedia. For example, if you plan to maintain an IT blog that includes training videos about new product features, you must ensure that you have enough space to do so.
8-35
Locating People and Expertise
Key Points
Enabling people to find colleagues who have valuable information is a key reason for enabling social computing features in your organization. People Search and expertise tagging in SharePoint 2010 enable My Site users to find other users based on their expertise and role in an organization. You can use this capability to help disseminate information throughout your organization.
Finding People and Expertise

You can plan for People Search and expertise tagging, which helps users to locate knowledge in your organization. People who have significant knowledge about a particular subject identify themselves by adding tags to their profile. People Search uses these tags when a user searches for a colleague who has knowledge about that subject. When you plan how to enable your users to find the information that they require, consider People Search and the Organization Browser.
8-36
People Search
Users can search for other users by using People Search, which returns links to relevant public profiles. Users can contact the colleagues they have located by using e-mail or messaging programs. Planning for People Search will affect planning for user profiles. In your initial planning for People Search, you may discover people or groups of users whom you want to be easy to find. You must plan to include the correct user profile properties and schedule appropriate user profile synchronization to ensure that these users are located easily. By examining your logical architecture and site hierarchy, you can determine key business concepts that relate to specific groups of users across sites. These groups will frequently be the subject of searches. You should plan for administrators of User Profile Service applications to work with the administrators of Search Service applications to develop search scopes and People Search tabs for these specific groups. You can also plan to allow site collection administrators to create site-level search scopes for users who are members of their site collections. You can enable e-mail analysis in Microsoft Outlook, although users can opt out of this feature if they want. If users are using Microsoft Office Outlook 2007, SharePoint 2010 imports colleague suggestions from Office Outlook. If your organization uses Outlook 2010, SharePoint 2010 analyzes colleagues and keywords and suggests relevant people and subjects to users.
Organization Browser
My Site features include an organization browser, which enables the user to view the organizations hierarchy. The organization browser is enabled by defaultyou can prevent users from seeing it by deleting the organization node from the Quick Launch. SharePoint 2010 imports organization information from a directory service such as Active Directory Domain Services, although you can create it manually if necessary. You must have Silverlight 3 installed to view the organization browser. Question: How does planning for People Search affect planning for user profile synchronization?
Additional Reading
For more information about how to enable SharePoint 2010 Colleague in Outlook 2010, see http://go.microsoft.com/fwlink/?LinkID=200890&clcid=0x409.
8-37
Lesson 3
Planning for the User Profile Service
The major driver for implementing social computing is to make people and expertise in the organization easier to find. User profiles hold information about people that users can search. To create an effective plan for using the User Profile Service to support social computing features, especially search, you must have a thorough understanding of user profiles, properties, and policies.
Objectives
After completing this lesson, you will be able to: Describe how the User Profile Service supports social computing. Explain how to plan user profile properties. Explain how to plan user profile policies. Explain how to plan the synchronization of user profile information. Describe the considerations for managing profiles in the organization. Describe Microsoft Business Connectivity Services (BCS).
8-38
The User Profile Service and Social Computing
Key Points
You should plan social computing features such as My Site Web sites in conjunction with planning for user profiles. The User Profile Service stores and manages information about users, and social computing features use this information. Consequently, the social computing features that you plan to deploy may affect the information that you plan to store in user profiles.
Features of the User Profile Service

The User Profile Service stores information in a central location. You should plan for service administrators to configure and manage the following features: User profiles. A user profile stores detailed information about the user in the form of properties. You can manage and display all of the properties that are related to each user along with social tags, documents, and other items that are related to that user.
8-39
Organizational profiles. Organizational profiles contain detailed information about an organization, such as teams and divisions. You can use organizational profiles to gain information about the organizational structure. Profile synchronization. User and organizational profile information that the User Profile Service stores is synchronized with external directory services such as Active Directory. A user profile can incorporate data from more than one source. You can schedule synchronization depending on how often you expect the relevant information to change. Audiences. Audiences enable you to target content to users based on their job or task. You can define an audience by membership in a SharePoint group or distribution list, by the organizational reporting structure, or by the public properties in user profiles. My Site Host. My Site Host is a dedicated site for hosting My Site Web sites. You must provision a My Site Host before you can deploy the social features of SharePoint 2010. My Site Web site. Each user in your organization who has a synchronized user profile can have a personal site. Users can manage the content of their My Site Web sites and can include features such as links, tags, colleagues, and documents. Social tags and notes. Users can add social tags to documents, to other SharePoint items, and to other objects, such as external Web pages and blog posts. Users can also create notes on any SharePoint page. Administrators can delete all tags for employees when they leave the company or remove a tag that they do not want.
User profiles provide profile information for social computing features, particularly the following: The user properties that are displayed on My Site Web sites. The organizational hierarchy that is displayed in the organization browser. The tags, notes, and comments that users create.
These features enable a user to stay informed about the content that interests them most. You should plan how to manage the User Profile Service in your organization. You can have farm administration perform all of the management tasks. Alternatively, you can delegate the management of all or part of the features of the User Profile Service to service application administrators.
8-40
Question: Why is it important to plan for the use of the User Profile Service alongside planning for social computing?
8-41
Planning User Profile Properties
Key Points
When you plan user profiles, you should determine the information about users that you require to support the social computing features that you plan to implement. The User Profile Service stores this information in user profile properties. When you plan user profiles, you should consider several factors: What are the existing directory services? The information that is held in these services forms the basis for user profiles. You should determine the properties that you will use for your core user profiles based on those that are relevant across the organization. Do any of the LOB applications that you use have information about users? Some LOB applications store properties that map to the properties of directory services. You can use these properties on personalized Web sites. How often do you want to synchronize records between the SharePoint profile store and the source directory service? The frequency of scheduled synchronization will depend on how often the content of the user properties changes. You
8-42
should plan to schedule synchronizations to have the least effect on performance and availability.
Default Profile Properties

SharePoint 2010 provides a set of default user profile properties. You should review these properties and the policies that apply to them before you decide which changes to make. Plan to use the default user properties wherever possible to minimize administrative effort. You may find that you have to create additional properties to support your user profile plan. Some user profile properties, such as first name and last name, are automatically mapped to corresponding properties in the external directory service or business system. For example, the following table lists the default mappings for users.
Active Directory Domain Services attribute <dn> objectSid manager displayName givenName Sn PhoneticDisplayName PhoneticFirstName PhoneticLastName telephoneNumber mail physicalDeliveryOfficeName title department sAMAccountName User profile store property SPS-DistinguishedName SID Manager PreferredName FirstName LastName PhoneticDisplayName PhoneticFirstName PhoneticLastName WorkPhone WorkEmail Office Title Department UserName
8-43
Active Directory Domain Services attribute wWWHomePage SIP Address
User profile store property PublicSiteRedirect proxyAddresses
Additional Profile Properties

You can create additional properties to track key information from directory services and business applications, if that information is not available through the default properties for these sources. Depending on the business requirements, you can plan to add properties at the level of the User Profile Service or site collection. You can often meet key business requirements by creating new properties that associate users with particular business processes. For example, you can create a Cost Center property to hold cost information for use in departmental budgets. Search can use these additional properties to find users, or personalization features can use the properties to target content to users. Profile properties do not have to be displayed on My Site Web sites or other accessible sites. Search or personalization features can use profile properties that are not displayed in public profiles or My Site Web sites. To limit the number of additional properties, you should focus on only adding properties that enable key business requirements for each site collection. You should identify a specific business requirement that an existing profile property cannot meet before you create a new one. Question: When should you create additional user profile properties?
8-44
Planning User Profile Policies
Key Points
Privacy is one of the concerns that you must plan for if your organization hopes to adopt social computing successfully. Users may be uneasy about who can see their data and may therefore resist putting information in their profiles. You must reassure users that their privacy will be respected and encourage them to supply relevant information for their profiles. Some information about individual users should remain private. Other information can and should be shared freely with other users to encourage collaboration. Policies are sets of rules that you can assign to users or groups to control how much information users can see and how they can interact with it.
Planning User Profile Policies

SharePoint 2010 provides default policies to help you make the appropriate information available to meet the requirements of the organization. You can also create and deploy custom policies if the default policies do not meet your specific requirements. You should review collaboration requirements across your organization before you develop a plan for implementing the best combination of policies.
8-45
To prepare for planning, you should assess the current visibility of the information about users in the organization. You should also consider who uses sites and which sites they use. For example, a central portal site in a large organization that has a large number of viewers, but very few contributors has less need to share information than a departmental site where many people can contribute content. You may include privacy issues in your security plan; privacy policies and security considerations relate closely, so it is beneficial to consider them together. You should also consider how the frequency of updates affects performance and capacity for the User Profile Service. Less restrictive policies allow more users to view public profiles more often, which affects how frequently you must update user profiles and compile audiences. In organizations that have many users, this frequent updating may affect performance and capacity planning.
Default and Custom Policies

Every personalization feature and property that user profiles and My Site Web sites expose has a recommended default policy. You can apply the default policy or create a custom policy to meet the requirements of your organization. Policies consist of two parts: the policy setting and the default visibility setting. Policy Settings You can configure policies to control the creation and population of a profile property. The policy settings are: Enabled. The property is visible depending on the visibility setting. Required. The property must be populated and is shared based on default access. Optional. The property is created, but may not be populated. Disabled. The property is visible only to the User Profile Service administrator. User Override. The user can change the default visibility setting.
Visibility Settings You can use the visibility settings to determine who can see information for a specific personalization feature. The visibility settings are: Everyone. Every user with viewer permissions can see information. My Colleagues. Every user in the users My Colleagues list can see information. My Team. Every user in the users team can see information.
8-46
My Manager. The user and the users immediate line manager can see information. Only Me. Only the user and the administrator of the User Profile Service can see information.
Additional Reading
For more information about how to plan for user profiles in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200891&clcid=0x409.
8-47
Synchronizing User Profile Information
Key Points
Profile synchronization enables you to synchronize user and group profile information that is stored in the SharePoint profile store with profile information that is stored in directory services and business systems. Profile synchronization occurs when profile information changes in either location. You can configure profile synchronization so that changes that are detected in either store are replicated to the other store. When you plan user profile synchronization, ensure that you plan for the instance of the User Profile Service to be on the same server as the User Profile Synchronization Service. When you design a user profile synchronization plan, you should consider the following guidelines: Identify directory services and business systems for synchronization. Plan permissions. Determine which containers to synchronize. Define profile synchronization connection filters.
8-48
Map profile properties. Define a synchronization schedule.
Identifying Directory Services and Business Systems

When you plan for profile synchronization in SharePoint 2010, you first have to determine the directory services and business systems with which you want to synchronize profile information. You can configure SharePoint 2010 to synchronize with directory services that are based on the Lightweight Directory Access Protocol (LDAP), such as Active Directory Domain Services, Sun ONE, Novell eDirectory, and IBM Tivoli. All of these directory services support full and incremental synchronization of users, but only Active Directory supports the synchronization of groups. You can also configure SharePoint 2010 to synchronize with business systems such as Siebel. The User Profile Synchronization Service imports profile information that is stored in business systems by using the Business Data Connectivity Service.
Planning Permissions
After you have identified the directory services and business systems with which you want to synchronize profiles, you must ensure that you have the required permissions on both SharePoint 2010 and the directory service or business system to which you will connect.
Determining Which Containers to Synchronize

You must determine which directory service containers have the user profiles and group profiles that you want to synchronize. This information is required for the initial configuration of the profile synchronization connection.
Defining Profile Synchronization Connection Filters

You should identify any profile information that you want to exclude from synchronization before the initial synchronization takes place. You can configure connection filters to exclude properties or entire accounts.
Mapping Profile Properties

When you have identified the containers that you want to import and synchronize with SharePoint 2010, you must map the profile properties in the directory service or business system to the profile properties in SharePoint 2010. You should also consider any properties that map across multiple directory services or business systems, because you must create these mappings manually.
8-49
Defining a Synchronization Schedule

SharePoint 2010 uses two different types of schedule: recurring and nonrecurring. Recurring schedules support only incremental synchronization, transferring only changed profile information. Nonrecurring schedules support either incremental or full synchronization. Your synchronization plan should begin synchronization with a nonrecurring full synchronization of user profiles only. When the full synchronization completes, you can deploy to the production environment and configure a recurring (incremental) synchronization of both user and group profiles. A full synchronization can take a significant amount of time to complete, sometimes days or even weeks. The time that it requires depends on several factors, such as the number of user or group profiles that you synchronize. The time that is required to complete an incremental synchronization depends on the number of profile changes that must be synchronized.
Additional Reading
For more information about how to plan profile synchronization in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200892&clcid=0x409.
8-50
Management of Profiles in the Organization
Key Points
To plan for the management of profiles in your organization, you must understand the User Profile Service architecture and determine who will perform day-to-day management tasks.
Managing the User Profile Service Architecture

SharePoint 2010 creates three databases for storing user profile information and associated data: A profile database. This stores user profile information. A synchronization database. This stores configuration and staging information. The User Profile Synchronization Service uses this information for synchronizing profile data from external sourcessuch as Active Directory and LOB applications. A social tagging database. This stores the social tags and notes that users create. Each social tag and note is associated with a profile ID.
8-51
SharePoint sites, My Site Web sites, and team sites access each of these databases by using the User Profile Service. This provides a dynamic, personalized experience for the users in an organization. Your plan for managing social computing should include a plan for managing and monitoring these databases.
Managing the User Profile Service

The approach that you take to managing the User Profile Service will vary depending on the nature of your organization. In small organizations, a single administrator can manage all areas of the User Profile Service. In larger or more complex organizations, you can isolate areas for management by different administrators who do not need to know about the existence of other areas of the service. For example, one administrator can manage My Site Web sites and a different administrator can manage social tags and notes. You can restrict the User Profile Service to certain departments or sets of sites based on business requirements, security restrictions, and budgets.
Managing Supporting Services

The User Profile Service relies on other shared services to implement the full range of social computing features in SharePoint 2010. These related shared services include: The Managed Metadata Service, which supports the use of managed metadata and shared content types across site collections and Web applications. The Search Service, which is required to enable People Search functionality.
Question: Which databases does the User Profile Service use?
8-52
Business Connectivity Services
Key Points
Many organizations use information that is stored in business systems such as Siebel or SAP. SharePoint 2010 supports BCS, a set of services and features that provide a way to connect SharePoint 2010 to sources of external data. Planning for BCS should include determining the nature of the solutions that your organization requires and planning for the security and administration of these solutions. You administer BCS primarily by using the Business Data Connectivity Service. SharePoint 2010 imports profile information that is stored in business systems by using the Business Data Connectivity Service. The User Profile Synchronization Service adds this data to the existing information that is imported from Active Directory or other directory services. For example, if a profile that contains the name and employee number for a user exists in the SharePoint 2010 profile store, you can augment this information with the hire date for that employee from another business system. To do this, you must plan for the configuration of the Business Data Connectivity Service, so that you can to connect to the business systems that you have identified.
8-53
Although you can import data from business systems, the User Profile Synchronization Service does not support the export of profile properties to business systems.
Additional Reading
For more information about how to plan for BCS in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200893&clcid=0x409.
8-54
Lab: Planning Social Computing
Exercise 1: Planning User Profiles

Scenario
Based on the organizations business requirements, you must plan which user profile properties to synchronize with Active Directory Domain Services. The information that your team needs is detailed in the supplied documents. Use these documents to produce your user profile property synchronization plan. The main tasks for this exercise are as follows: 1. 2. Read the supporting information. Complete the User Profile Property Planning worksheet.

1. Read the lab scenario.
8-55
2. 3.
Log on to 10231A-NYC-DC1-08 as CONTOSO\Ed with the password Pa$$w0rd. In the E:\Labfiles\Lab08\Starter folder, read the information in the User Profile Requirements.docx file.
Task 2: Complete the User Profile Property Planning worksheet

In the E:\Labfiles\Lab08\Starter folder, complete the worksheet in the User Profile Property Planning Worksheet.xlsx file.
Exercise 2: Configuring User Profile Synchronization

Scenario
You must now perform the configuration tasks that are necessary to implement your plan. You will also verify that the correct user profiles are synchronized. The main tasks for this exercise are as follows: 1. 2. 3. 4. Configure Active Directory permission for synchronization. Create a synchronization connection and a connection filter. Run the user profile import. Confirm the user profile synchronization by checking that the Ed Meadows and Adam Carter profiles were imported and that the Neil Charney profile was not imported. Provision Ed Meadows My Site Web site.
5.
Task 1: Configure Active Directory permission for synchronization

1. In Active Directory Users and Computers, delegate control of the Contoso.com domain to the SharePoint farm account. Use the information in the following table to complete the Delegation of Control Wizard.
Option Users and Groups Tasks to Delegate
Value sp-farm Create a custom task to delegate
8-56
Option Active Directory Object Type Permissions
Value This folder, existing objects in this folder, and creation of new objects in this folder General Replicating Directory Changes
2.
Verify that the user account for Neil Charney (in the Production Organizational Unit) is disabled.
Task 2: Create a synchronization connection and a connection filter

1. In SharePoint 2010 Central Administration, under Application Management, click Manage service applications, and then click User Profile Service Application. Under Synchronization, click Configure Synchronization Connections. Create a new connection for the User Profile Service application. Use the information in the following table to configure the new connection.
Option Connection Name Forest name Account name Password Populate Containers Value Contoso Contoso contoso\sp-farm Pa$$w0rd IT, Marketing, and Production
2. 3.
4.
Edit the new Contoso connection to create a filter that excludes disabled user accounts. Use the information in the following table to add the filter for users.
Option Attribute Operator Filter Value userAccountControl Bit on equals 2
8-57
Task 3: Run the user profile import

1. 2. 3. In SharePoint 2010 Central Administration, start the User Profile Service application. Refresh the page, watching the Profile Synchronization Status as the synchronization proceeds. When the Profile Synchronization Status returns to Idle, click Idle to view the synchronization report.
Task 4: Confirm the user profile synchronization by checking that the

Ed Meadows and Adam Carter profiles were imported and that the Neil Charney profile was not imported
1. In SharePoint 2010 Central Administration, on the Manage Profile Service: User Profile Service Application page, under People, click Manage User Profiles. Find and view the user profiles for Ed Meadows and Adam Carter. Attempt to locate the user profile for Neil Charney. This user account is disabled, so the profile has not been imported. Therefore, the search result is empty.
2. 3.
Task 5: Provision Ed Meadows My Site Web site

1. 2. 3. In SharePoint 2010 Central Administration, create a My Site Web site for Ed Meadows. Wait for the page to be created. To verify that the My Site has been created, view the My Content and My Profile pages.
8-58
Review Questions
1. 2. 3. What are the services that support My Site Web sites? How can you help to secure personal information on My Site Web sites? What functionality does BCS provide for social computing?
Best Practices Related to Social Computing

Supplement or modify the following best practices for your own work situations: Social computing is about finding people and expertise. If you provide users with a quick and easy way to find what they need, it will become selfperpetuating, with users adding and maintaining their own content.
8-59
User education is key. Set firm guidelines about what type of content users can post, and tackle their privacy concerns by using permissions and policies to help secure content. Consider deploying social computing features a little at a time. Configure user profiles and My Site Web sites, and then establish a tagging culture. Include wikis and blogs where useful.
Designing an Enterprise Search Strategy
9-1
Module 9
Contents:
Lesson 1: Overview of SharePoint 2010 Search Architecture Lesson 2: Search Topologies in SharePoint 2010 Lesson 3: Capacity and Performance Planning for Search Lesson 4: Mapping Business Requirements to Search Design Lab: Designing an Enterprise Search Strategy 9-4 9-19 9-28 9-40 9-51
9-2
Module Overview
Search is a very important feature of Microsoft SharePoint 2010, which is implemented as a service application. Most organizations cite the ability to find content from all over their enterprise environment as a reason to consider implementing SharePoint. The search facility applies both to new content uploaded to SharePoint and to content from other locations, such as file shares or Microsoft Exchange public folders, or other line-of-business (LOB) applications. This enables an organization to present SharePoint as a single interface to many different content repositories. Even if something is not stored in SharePoint, users can still find it by using SharePoint. SharePoint now offers improved search integration with computers running Windows 7, so this can become a natural extension of how users reach the content that they need.
9-3
Objectives
After completing this module, you will be able to: Describe the search architecture and process in SharePoint 2010. Describe the topologies that are available in SharePoint 2010 to service a range of search requirements across business models. Plan and document enterprise search for capacity and performance. Describe how to map business requirements to the SharePoint Enterprise and FAST search architectures.
9-4
Lesson 1
Overview of SharePoint 2010 Search Architecture
Before you plan or design search requirements and support for your SharePoint farm, you must understand how the search feature in SharePoint builds a content index for searching. The search service application includes many components. Understanding how SharePoint uses these components will help you to identify which components you may need to implement, scale up, or scale out, to meet different business requirements.
Objectives
After completing this lesson, you will be able to: Identify the licensing requirements for SharePoint search. Identify crawl, query, and database components that SharePoint search requires.
9-5
Identify the high-level crawl process. Configure crawl behavior. Plan security accounts for SharePoint search. Plan search federation.
9-6
SharePoint 2010 Licensing and Search
Key Points
SharePoint 2010 is available in various editions, with various feature sets. Specific feature sets require specific licensing. You must understand how licensing affects SharePoint search and how to license search options when you are planning to implement SharePoint search in your environment. SharePoint 2010 requires both server licenses and client access licenses (CALs). CALs can apply either per user or per device depending on the user access requirements in the organization. In addition, CALs are available as standard CALs or enterprise CALs. Standard CALs license users for standard features in SharePoint 2010, such as collaboration, publishing, or My Sites. Enterprise CALs license users to use enterprise features such as Excel Services, Visio Services, or InfoPath Forms.
Note: Enterprise CALs are cumulative. This means that if 1,000 users require enterprise features, you will need 1,000 standard CALs and 1,000 enterprise CALs.
9-7
Standard CALs for SharePoint Server 2010 include SharePoint enterprise search functionality. This includes the ability to index diverse content sources, including: SharePoint content Web site content File share content Exchange public folder content Other database content
You can also scale out the SharePoint search server topology to maintain search performance. Depending on your licensing configuration, SharePoint Server 2010 also has FAST search capabilities. To implement FAST search for SharePoint 2010, you require: SharePoint server licenses. A FAST search server license for any servers running FAST search. Enterprise CALs for any users using FAST search.
FAST search includes the following benefits: Support for 500 million items. Visual best bets (HTML rendering). Sort on any indexed property. The ability to preview Microsoft Word or Microsoft PowerPoint documents on the results page. Deep refinement showing count by property refinement. The ability to document thumbnails on the results page. FAST search Web Parts. Manual promotion or demotion of specific results. Relevancy profiles to show different results ranking to different users. Multilingual search controls.
9-8
Note: FAST search uses SharePoint search to index user profile data and perform People Search queries. This means that FAST search complements SharePoint search, but does not replace SharePoint search.
Additional Reading
For more information about SharePoint editions, see http://go.microsoft.com/fwlink/?LinkID=200894&clcid=0x409. For more information about SharePoint licensing, see http://go.microsoft.com/fwlink/?LinkID=201240&clcid=0x409.
9-9
Enterprise Search Architecture
Key Points
The search architecture in SharePoint 2010 has changed significantly from previous versions of SharePoint. The Search Service Application (SSA) has three primary components: The index server role hosts one or more crawlers, which connect to and index content from various sources, including: SharePoint content Web sites File shares Exchange public folders Lotus Notes content
Crawlers enumerate the source content and pass text information to the relevant index partition on the query server. The crawler also indexes any metadata to the search property database and updates the crawl status in the crawl database.
9-10
The query server role hosts one or more index partitions to provide results to search queries from users. Users enter a search query on a Web Front End (WFE) server, which then directs the query to a query server. The query server retrieves information from the index partition stored on the local file system of the query server, and metadata information from the search property database. Database servers in the farm host a search administration database, one or more search property databases, and one or more crawl databases for each SSA: The search administration database holds search configuration details such as best bets and index access control lists (ACLs) for security trimming purposes. The search crawl database holds information about the status of crawls, crawled items, and crawl history. The search property database holds information associated with crawled items, such as properties (metadata) and crawl queues.
Note: The index server role does not hold a copy of any index partitions as in previous versions of SharePoint. The crawler constructs index partitions directly on query servers.
The FAST search architecture complements the SharePoint search architecture with a similar mechanism, but additional server roles. To implement FAST search, you must implement one or more FAST index server roles and one or more FAST query server roles.
Additional Reading
For more information about SharePoint search architecture, see http://go.microsoft.com/fwlink/?LinkID=167739.
9-11
Crawling Content in SharePoint 2010
Key Points
To connect to and crawl content in SharePoint 2010, the index server role and the crawler component must understand how to connect to the content source, and how to read the type of content that is stored at the content source. When the crawler starts the crawl of a content source, it first looks at the URL of the content source and makes the appropriate connection. After connecting to the content source, the following steps occur: 1. As individual items such as Web pages or documents are crawled, the crawler streams metadata, or document properties, into the search property database. The crawler must also understand the formatting and, in some cases, the binary storage format of the item. The crawler uses an iFilter to open files, extract the text, and discard the formatting.
Note: By default, SharePoint includes iFilters for documents in Microsoft Office 2003, 2007, and 2010; HTML; text files; XML; and TIFF files. To index other file types, you must install additional iFilters.
9-12
2.
The crawler also performs word breaking, that is, separating the content into discrete chunks. Word breakers are characters such as punctuation or spaces that SharePoint uses to identify the end of one word, and the start of another. Finally, the crawler drops noise words, such as at, the, and is, which are typically not useful to the result set because of the large number of matches.
3.
9-13
Controlling Crawl Behavior in SharePoint 2010
Key Points
When you are planning to crawl and index content in SharePoint 2010, you must understand how to configure the crawler component to ensure that: Content is up to date. The correct content is indexed. The crawler does not overload the content source with requests.
Crawl Schedules
You can configure full and incremental crawl schedules with the content source settings. Crawl schedules control how frequently you want the crawler to index content, thus controlling how current the index is. If you want users to be able to search for the latest content, you should ensure that you perform frequent crawls of the content (either incremental or full crawls). However, more frequent crawls will increase the load on the index, WFE, and database servers. Incremental crawls only index changed content, so an incremental crawl is typically much faster. You
9-14
may consider performing more frequent incremental crawls to keep the index as up to date as possible.
Note: SharePoint does not automatically index content when users add or upload content to a SharePoint site. SharePoint only indexes content during a full or incremental crawl.
Crawl Rules
You can use crawl rules to specify certain crawl behaviors. For example, you may want to crawl your existing intranet site, which is not based on SharePoint technology, but avoid crawling the template section of the site, which includes empty document templates. You could use a crawl rule to exclude the address of the template site from the index in SharePoint. You can use crawl rules to: Exclude or include specific address paths. Exclude or include complex URLs (addresses that contain question marks). Specify a user account to connect to the address, other than the default account.
In SharePoint 2010, you can also create crawl rules that use regular expressions. Regular expressions are a way of describing attributes that match a certain format, such as URLs that contain social security numbers.
Crawler Impact Rules

When you are planning to crawl content sources outside the farm where the SSA is configured, you must consider the impact that crawling content will have on the content source itself and the users accessing the content source. If the crawler tries to index all of the content on the public Web site of the organization as fast as possible, the number of requests that the crawler generates could significantly reduce the performance of the public Web servers. This would effectively create a denial of service to other legitimate users. You can use crawler impact rules to control how many requests the crawler can make for a specific path, and whether the crawler should pause between consecutive requests. In this way, you can throttle how quickly the crawler can index a site or location, and how resource-intensive the crawl process is.
9-15
Planning Security Accounts for SharePoint Search
Key Points
You must configure SharePoint search with user accounts for the search service application and content access. SharePoint uses the user account that you configure for the search service application as the security context for running the search service. SharePoint search uses the content access account to connect to content sources and crawl content. For this reason, it is important that the content access account has read permission to required content sources. When you configure the SSA and specify the default content access account, SharePoint automatically grants the default content access account the necessary read permissions to the SharePoint content databases in the same farm. When you perform a search, SharePoint automatically shows only search results that are relevant and that you have permission to access. This mechanism is called security trimming. For SharePoint to perform security trimming on search results, the content access account must not have administrative permissions on the content sources that it is crawling.
9-16
For accessing content sources that are external to SharePoint, the SSA can use the default content access account, or you can specify a different account by using a crawl rule.
9-17
Planning Search Federation
Key Points
Search in SharePoint 2010 includes a federated search component. Federated search enables SharePoint search to forward a search query to other, preconfigured search services that use OpenSearch technologies, such as Bing or a different SharePoint farm search instance. You configure federated search by adding federated locations to the SSA. You can also control whether SharePoint always queries the federated location, or only queries the federated location if the search matches a specific prefix or pattern. This is known as the trigger. For example, you could configure all queries to search Bing in addition to SharePoint search, but queries that start with the words weather check, such as weather check London, would be sent to a different federated location.
Note: In the previous example, SharePoint search would only send the word London to the federated search location.
9-18
You can use federated locations to provide a means for searching other SharePoint search applications. For example, you could use federated search during a migration from a Microsoft Office SharePoint Server 2007 farm to a SharePoint Server 2010 farm to remove the need to crawl the Office SharePoint Server 2007 content from the SharePoint Server 2010 farm. When you plan your SSAs, you should include planning for the number of federated locations that you should include and the type of trigger that you require for each federated location.
9-19
Lesson 2
Search Topologies in SharePoint 2010
When you plan search for a SharePoint farm, various topology options are available to you. Before you size your search environment, you should be aware of which search components you require, and how you can scale search components to meet the needs of your users and content repositories.
Objectives
After completing this lesson, you will be able to: Identify options for SharePoint search topologies. Scale out index components in a SharePoint farm. Scale out query components in a SharePoint farm. Identify options for FAST search topologies.
9-20
SharePoint Search Topology
Key Points
In a SharePoint farm, you can specify the number of SharePoint servers that will perform the index and query roles independently. You can implement multiple servers for index or query roles, and you can split the index into partitions for reasons of high availability or performance: In a small, two-tier farm environment, you may start with a mix of query and index roles on one server. However, one of the first aspects to consider for performance purposes is to separate the query and index roles. In a small, three-tier farm environment, the query role typically runs on the WFE server and the index role runs on the application server. In this environment, you could also add an additional database server for search databases to help improve search performance. In a medium farm (or a small farm where you consider search to be critical), you can assign the query role to multiple servers to improve query performance or to provide high availability for the query role. You can also assign multiple servers to host the crawl role so that you can improve crawl times and provide high availability to the crawl role. As farm size increases, you
9-21
can add additional servers to host the query or crawl roles to further improve query responses or index freshness. In large farms, you can dedicate several servers to search roles, with multiple dedicated query servers to improve query response times and multiple dedicated crawl servers to improve crawl speeds.
9-22
Scaling Out Index Servers
Key Points
The search architecture in SharePoint 2010 is highly scalable, so you can support indexing a corpus of up to 100 million items. To achieve this scaling, you can add multiple index servers to the farm that is performing the crawl and hosting the index. Scaling out index components can also improve crawl times and provide a fresher index for users to search. You can scale out the index mechanism in a farm by adding new crawl components to existing crawl databases or adding new crawl components with new crawl databases: The crawl component connects to the content source and crawls the content, creating or updating a temporary index. This index is propagated automatically to query servers in the farm. The crawl database holds information about crawl status, crawl items, and crawl history.
9-23
You can add more crawl components on additional servers by using an existing crawl database to achieve high availability and a performance improvement for the crawl process. You can add a crawl database to distribute the crawl load between different servers in the farm. Adding a crawl database requires you to add a crawl component because you can only map crawl components to one crawl database. When the farm contains multiple crawl databases, SharePoint attempts to balance the crawl load between the databases, based on the host headers that the Web applications are using. For example, suppose that you create two crawl databases (with associated crawl components) and you have two Web applications in your farm that have the host headers intranet.contoso.com and extranet.contoso.com. SharePoint will use one crawl database for intranet.contoso.com and the other crawl database for extranet.contoso.com. You can also use host distribution rules to control which databases and crawler components SharePoint uses to crawl which hosts. This is useful where you want to control which crawl component and which server SharePoint uses to crawl larger content sources, or if you want to group several small sources together.
9-24
Scaling Out Query Servers
Key Points
To scale query functionality, you must understand the individual components that queries use. The following table lists the query components.
Component Index partition Description Unlike previous versions of SharePoint 2010, the index is now only stored on query servers. You can divide the index into parts called index partitions. An index partition contains part of or the entire index. Query components map to index partitions and property databases. You can create additional query components for an existing index partition. These mirror query components provide fault tolerance for executing search queries. You can also create additional index partitions to break down the index into smaller parts for distributing across multiple servers. Each index partition requires an associated query component. This can help to reduce query latency (how long a query takes to execute).
Query component
9-25
Component Property database
Description The property database holds information such as metadata, which a search query must include when it executes a search. You can create additional property databases to improve query performance, but a query component must hold a mapping to a unique property database. In practice, this means that creating an additional property database requires you to create an additional index partition with a unique query component. However, creating an additional index partition does not require you to create an additional property database.
Query processor
The query processor runs under the w3wp.exe process. It executes each search query, retrieves search results from the property database and the query components, packages the results, and delivers the results back to the requesting WFE server. The query processor queries a copy of each index partition and property database for results. If multiple mirrors of an index partition exist, the query processor load-balances requests between different index partition mirrors. The query processor can run on any server.
To provide fault tolerance, you can create mirrors of an index partition on additional servers. To reduce query latency, you can create index partitions on additional servers. You can also mix these options by adding servers to the farm and provisioning mirrors of multiple index partitions so that you provide fault tolerance and performance improvements.
9-26
FAST Search Topology
Key Points
If you plan to deploy FAST search for SharePoint 2010, you must plan the number of FAST search servers and the FAST search topology to follow. FAST search works on similar principles to SharePoint search. FAST search uses separate index and query components, and similar scale-out mechanisms for the purposes of fault tolerance or performance. FAST search scaling works with the principle of rows and columns: An index column represents part of or the entire searchable index. You can break the index into multiple columns if the index becomes too large to manage as a single entity. A single index column should contain no more than 15 million items with the default configuration. A search row represents a set of search nodes that contain the entire index. A search row consists of one search node for each index column. You can deploy additional search rows (with corresponding search nodes) to provide improvements to fault tolerance or query performance.
9-27
Note: You can also create additional index rows, such as a backup index row, in addition to the primary index row for fault tolerance in the index process. However, this does not improve crawl performance.
9-28
Lesson 3
Capacity and Performance Planning for Search
When you understand how you can scale out search components, you can start planning the quantity of storage that search components require and the number of servers that search requires. You can use several calculations to provide an estimate of the search storage requirements. However, the index and query components often require performance testing to establish crawl times for a content source, or query response times for users. Under these circumstances, you can plan options for index or query components to bring the search performance in line with business requirements. In addition, if you deploy FAST search, the component sizing behaves differently, so sizing a FAST search deployment is different to sizing a SharePoint search deployment.
Objectives
After completing this lesson, you will be able to: Plan capacity for SharePoint search. Improve index performance.
9-29
Improve query performance. Plan capacity for FAST search.
9-30
Capacity Sizing for SharePoint Search
Key Points
To plan capacity for SharePoint search, you must recognize each of the components that require storage, the storage medium, and the sizing requirement. Most search sizing calculations are a factor of the size of your corpus, which is the total body of content that you plan to crawl and index. Use the figures and calculations below as an estimate or starting point for the environment that you are planning. Due to the nature of various content sources and types of content, you may discover that you require more or less than your estimate.
Index Requirements
Index partitions are stored on query servers. To determine the total index size, use the following formula: TotalIndexSize = CorpusSize 0.035 This estimates the total index. To calculate the storage requirements for each query server, you must know the number of index partitions and mirrors that you require. From a capacity perspective, an index partition should hold no more than
9-31
10 million items. SharePoint automatically divides the index evenly among all active (nonmirrored) index partitions. You can calculate the storage requirement for a partition (or mirror) by using the following formula: QueryComponentSize = TotalIndexSize NumberOfPartitions For each query server, you must also allow additional disk space for index updates and index merging. To calculate disk requirements, use the following formula for each query server: IndexStorage = QueryComponentSize 3 NumberOfQueryComponents In addition, you should plan enough RAM for the query server to hold a third of all active index partitions. For example, if the query server holds two active partitions, each of which is 10 GB, the server should have at least 8 GB of RAM.
Search Property Database Requirements

The search property database requires storage space on a server running Microsoft SQL Server in the farm. The following formula estimates the size of the property database: TotalPropertyDBSize = CorpusSize 0.015 SQL Server databases also require log file storage to process changes. The following formula estimates the log file size for the property database, based on the assumption that you use the simple database recovery model: TotalPropertyLogSize = CorpusSize 0.0031 This is the total size for the property store. If you plan to implement more than one property database, you should divide your calculations between different property databases accordingly.
Note: As a guideline, one property database can contain up to 50 million items.
As a minimum, the server running SQL Server that is hosting the property databases should be able to store a third of the property database in RAM.
Search Crawl Database Requirements

Search crawl databases are stored on servers running SQL Server in the farm. You can use the following formula to estimate the storage requirements for the crawl database: TotalCrawlDBSize = CorpusSize 0.046
9-32
The following formula estimates the log file size for crawl databases, based on the assumption that you use the simple database recovery model: TotalCrawlLogSize = CorpusSize 0.011 For memory, it is recommended that index servers have at least 16 GB of RAM.
Note: Typically, crawl databases should not contain more than 25 million items.
Search Administration Database Requirements

The search administration database is typically smaller than 10 GB.
Note: Backing up the search application will require the sum of all unique index partitions, crawl databases, property databases, and the search administration database.
Question: What factors could mean that you require more or less space than the calculated values given in this topic?
Additional Reading
For more information about capacity sizing for search, see the Calculate storage sizing section in the white paper called Search for SharePoint Capacity Planning (SearchforSPServer2010CapacityPlanningDoc.docx) at http://go.microsoft.com/fwlink/?LinkID=200895&clcid=0x409.
9-33
Improving Index Performance
Key Points
There are three typical scenarios that can affect crawl performance and reduce the freshness of the index: An input/output operations per second (IOps) bottleneck in the crawl subsystem. A performance bottleneck on the index server. This is typically the result of a lack of CPU threads. A bottleneck at the content source, such as slow repository responsiveness.
You can identify search performance issues from information such as the crawl history and search administration reports.
Crawl IOps Bottleneck

If the performance issue is due to an IOps limitation on the crawl or property databases, consider adding another crawl database (which enables the system to achieve more IOps). You may be able to add another crawl database to the existing
9-34
server running SQL Server to provide additional IOps. Alternatively, you may need to provision another server running SQL Server to provide higher IOps.
Crawl CPU Thread Bottleneck

If the crawl subsystem does not have an IOps bottleneck, you may need to consider the crawler performance. First, to provide more CPU resources to the crawl subsystem, check whether the indexer performance level is set to Partially reduced or Maximum. Next, if the index server has spare CPU capacity, you can use crawler impact rules to increase the number of threads that are assigned to retrieving content to speed up the crawl. The ideal solution to increase crawl speed, particularly where there are a large number of content hosts, is to add more crawl components on additional servers. In this way, you can increase the CPU resources that are available for crawling content.
Crawl Bottleneck on Repository

In some cases, the crawl subsystem may spend a significant amount of time waiting for the content host to return requested content for crawling. You can check whether the bottleneck exists at the repository by determining whether the following conditions are true: There is a low (less than 20 percent) CPU utilization on the index servers. A large number of threads are waiting on the network (the OSS Search Gatherer/Threads Accessing Network performance counter records this value).
If such a condition exists, you must investigate the reason for poor performance. If the slow content repository is a SharePoint source, examine capacity and performance guidelines for the farm to determine the optimal configuration. For example, you may need to add WFE servers to the farm, or configure crawls at different times. Question: If the server running SQL Server that is hosting the crawl database has fully utilized its CPU and RAM, what solution would you propose to improve crawl performance?
9-35
Additional Reading
For more information about capacity sizing for search, see the Search crawl system optimizations section in the white paper called Search for SharePoint Capacity Planning (SearchforSPServer2010CapacityPlanningDoc.docx) at http://go.microsoft.com/fwlink/?LinkID=200896&clcid=0x409.
9-36
Improving Query Performance
Key Points
You may identify issues over query performance at an early stage, for example, during a pilot phase when users complain that search takes too long. Alternatively, you may have specified a goal for query processing when you specified requirements for the farm. You can implement various options to improve query performance, but as with index performance, you must examine which part of the query process is causing a bottleneck: If the query latency (the time taken to display results) is high, consider dividing the index into smaller index partitions. This is particularly effective if the portion of query time that is spent in the full text index is high. You can establish the breakdown of query performance by viewing the SharePoint back-end query latency report. Do not create too many smaller index partitionson each query server, you should have two processors for each active index partition. If the query throughput is low (the overall number of query requests per second), consider adding more query components (using more servers) to the existing index partitions.
9-37
If the property database is at the maximum level of IOps on the server running SQL Server, consider creating additional (small) property databases on the same server running SQL Server.
Note: SQL Server 2008 Enterprise offers a page compression feature, which can provide some IOps performance gains.
If the server running SQL Server that is hosting the property database is close to maximum memory/CPU utilization most of the time, consider upgrading the server with additional memory or CPU cores, or provisioning an additional server running SQL Server to host additional property databases.
Additional Reading
For more information about improving query performance, see the Search query system optimizations section in the white paper called Search for SharePoint Capacity Planning (SearchforSPServer2010CapacityPlanningDoc.docx) at http://go.microsoft.com/fwlink/?LinkID=200897&clcid=0x409.
9-38
Capacity Sizing for FAST Search
Key Points
To plan capacity for FAST search, you must recognize each of the components that require storage, the storage medium, and the sizing requirement. Most search sizing estimates are a factor of the size of your corpus. Using FAST search, all index data is stored on the file system of the index and query servers. FAST search does not use the property database that is provided for SharePoint search.
FIXML Data
FAST search stores processed items as FIXML data. FAST search uses this data as input to the indexing process to build indices. FAST search deletes old FIXML data daily, as new items cycle through the index process. The following formula estimates the FIXML storage requirements: FIXMLSize = CorpusSize 0.05
9-39
Index Data
FAST search stores the index on index servers and query servers. The index includes metadata in addition to standard item references. The following formula estimates the index data storage requirements: TotalIndexSize = CorpusSize 0.14 This estimates the total index. To calculate the storage requirements for each query server, you must know the number of index columns that you require. From a capacity perspective, an index column should hold no more than 15 million items in the default configuration. FAST search automatically divides the index evenly between all index columns. You can calculate the storage requirement for a single index column by using the following formula: IndexColumnSize = TotalIndexSize NumberOfColumns For each index and query server, you must also allow additional disk space for index updates and index rebuilds. To calculate disk requirements, use the following formula for each query server: IndexStorage = QueryComponentSize 2.5 NumberOfQueryComponents
Additional Index Data

In addition, FAST search requires some additional data storage for elements such as a Web analyzer and log data. The following formula estimates the additional data storage requirements: AdditionalData = CorpusSize 0.005
Note: FAST search does not include People Search data, so the estimates that are provided do not include People Search data. You must configure SharePoint search to provide the People Search component when required.
Additional Reading
For more information about capacity sizing for search, see the Disk Usage section in the white paper called FAST Search Server 2010 for SharePoint Capacity Planning (FASTSearchSharePoint2010CapacityPlanningDoc.docx) at http://go.microsoft.com/fwlink/?LinkID=200898&clcid=0x409.
9-40
Lesson 4
Mapping Business Requirements to Search Design
After you have identified how you can build SSAs into a SharePoint farm and established performance guidelines for search, you must reflect your organizations business needs in your search implementation. Should you choose FAST search or SharePoint search? Should you build search into the farm or build a dedicated search farm? Do you require high availability? You can answer all of these questions by examining the business requirements and using them to drive your decision-making, based on your understanding of how the SSA behaves.
9-41
Objectives
After completing this lesson, you will be able to: Identify key search planning decisions. Identify the business reasons for using FAST search. Plan taxonomy support for search. Plan search administration.
9-42
Planning Search Requirements
Key Points
In planning search for SharePoint solutions, you must focus on a series of factors that may lead the search design in different directions. When you are planning the initial search architecture and topology, you must answer key questions to shape the search design. The key design questions include: What is the corpus size, and are there any key search feature requirements? If the corpus size is above 100 million items, you could not support a single SharePoint search application. You could choose FAST search, which supports higher index item counts. Users may require specific search features, such as thumbnails or visual best bets, which are only available to implementations of FAST search. What is the corpus size, and how many SharePoint farms exist? If you have a very large corpus (more than 50 million items) or several SharePoint farms in an enterprise environment, you may consider
9-43
implementing a search farm (either dedicated or with other service applications). If you have multiple farms, but want to use local SSAs in each farm, you should consider if and how users in one farm can see search results from a different farm. For example, you could use search federation to show results from other farms, although SharePoint ranks each set of federated results separately. The corpus size will also help you estimate the search storage requirements. What are your crawl performance requirements? Understanding the size of your corpus, how fresh you should keep the index, and crawl component performance will help you to decide on the number of servers, the number of crawl and property databases that you require, and the performance options for the index servers. What are your query performance requirements? Do you have specific query performance requirements, such as displaying all search results within two seconds? If you have specific requirements, you can conduct performance testing and use tools such as query reports to analyze the query mechanism. Understanding your query performance requirements will help you to decide how many index partitions and query servers you require. Do you require high availability for search? This will typically be related to your high-availability choices for the rest of the farm deployment. If you have chosen to implement high availability in the farm for Web content, you should consider whether users will also require search functionality to be highly available. If search should be highly available, does that include both query and index components? You can implement high availability by adding index and query servers to the farm and configuring the additional crawl and query components accordingly. You must also implement some form of SQL Server high availability for the crawl, property, and search administration databases, such as SQL Server database mirroring or SQL Server failover clustering.
Question: What is the maximum recommended number of items for each index partition?
9-44
Business Reasons for FAST Search
Key Points
When you are planning search for your SharePoint environment, a key decision that you must make is whether to use only SharePoint search or implement FAST search for SharePoint. In some cases, you may base your decision on corpus size because FAST search can offer indexes of up to 500 million items whereas SharePoint search can only support up to 100 million items for each search application. However, in many cases, you may base your decision on the additional capabilities of FAST search. Reasons for an organization to choose FAST search include: The ability to sort results on any crawled property such as metadata. The ability to manually promote or demote specific results in the result set. The ability to provide relevancy to the search with user context. That is, two people can see the same results, but the results are ranked differently according to the job role, location, or expertise of the two people. Support for two-way synonyms.
9-45
Visual enhancements such as visual best bets, document thumbnails, or previews of Word or PowerPoint files directly on the results page. Improved grammatical support, including additional lemmatization or stemming of words. For example, a search for better could include search results for good.
FAST search does not include People Search. You must use SharePoint search to provide People Search results. Question: Does SharePoint search provide support for synonyms?
9-46
Planning Taxonomy Support for Search
Key Points
When you are planning search for your SharePoint environment, you may want to consider how metadata and your taxonomy will impact or assist search from a user perspective. When a user searches for something in SharePoint, SharePoint often returns a large result set that contains hundreds or thousands of results. This is particularly common if the user enters a common term. Users can use metadata in two ways to help make sense of and refine search results: Users can use metadata properties and values to filter search results. When SharePoint displays the results page of a users search, if any files or items in the results have metadata properties, the user can select those properties from a list on the results page to refine the search results based on these tags. SharePoint search typically adds managed metadata values to this list automatically under the Tags heading. Users can search for information by metadata field. If you have a metadata field called Project ID in your farm, you may want users to be able to search
9-47
for all items related to Project A, which is specified in the Project ID column. Users can do this in two ways: Enter a property search in the search box, using the <property>:<value> syntax. For example, Project ID:Project A. From the advanced search page, choose Project ID from the property restrictions list of properties.
To enable searching by metadata value, you must add a managed property for the metadata field, and map this managed property to one or more crawled properties (which is the set of properties that the last crawl discovered). This is often referred to as promoting the property. In addition, for the second option of choosing the property from the property drop down list on the advanced search page, you must edit the XML for the search Web Part to incorporate the managed property reference. In addition, you must configure the out-of-the-box search Web Parts to support the new managed properties if you want the user to be able to use them through the search user interface.
Note: You can only map a managed property to a crawled property after the search application has performed a crawl on that property.
Question: When you are trying to establish which properties might require promotion, who should you include in discussions?
9-48
Planning Search Administration
Key Points
In addition to planning the search topology, crawl schedule, crawler impact rules, and metadata integration, you should also consider who should administer certain nontechnical aspects of search. When a SharePoint farm is in pilot or production phases, many organizations discover additional refinements that can further improve the user search experience: You can use best bets to help users find key content by promoting a specific location, item, or document into the best bets result list, making them easier to locate. An administrator, such as a site collection administrator, must manually configure each best bet entry, which has one or more associated keywords. SharePoint search displays best bet results separately to ranked search results. You can add synonyms for specific words to help users include search terms that they may be unaware of, but that relate to the search term that they originally entered. You can add synonyms to the thesaurus file on the query servers to provide additional search results when users query specific search terms. Synonym matches can supplement results that are provided for the
9-49
original query, but you can also configure synonyms to replace the original search term. Thesaurus files typically require server administrator permissions to update. You can create search scopes to help users search only within a specific path or content source, which can further refine the search results. Search scopes narrow a query by restricting the result set. You can create search scopes based on a content source, a Web address, or a specific metadata property match. You can use search scopes to show only results that match the scope requirement, or to exclude results that match the scope requirement. You can create search scopes at the search application level or at the site collection level. You can examine query reports that identify top queries and queries that return zero results. Results that show zero results are often mistyped queries, or may be terms that the user assumes are available when no results exist. If considerable numbers of searches are being performed that use the same words and return zero results, it may be useful to create a synonym for the search term to automatically include other terms for which there are results. You may also consider creating a best bet to provide a notice for users to try other terms in the search. You can specify authoritative pages in the site collection to affect the ranking of search results. The search ranking engine uses click distance from authoritative pages as a factor in deciding how to order search results. You can add specific sites as authoritative sites to help search matches in certain sites to move higher up the search results order. Authoritative pages only form a small part of the ranking engine, so the use of authoritative pages is not an exact science. Other factors that also affect the ranking may still mean that certain results stay lower down the search results.
In many organizations, staff in the IT department are not the best people to configure these enhancements because they lack in-depth knowledge of metadata, content use, and key content locations. Non-IT staff can review and enhance the search experience if you provide the requisite users with appropriate permissions and training. Site collection administrators can perform the following search administration tasks: Configure keywords and best bets. Create search scopes in the site collection.
9-50
Search application administrators can perform the following search administration tasks: View query reports. Create farm-wide search scopes. Set authoritative pages.
Note: To enable additional users to perform search application administration tasks, you must delegate permissions to the search application in Central Administration.
For synonyms, consider a means of updating or notifying a SharePoint administrator with new synonym requirements. Typically, adding synonyms is useful for search queries that produce no results, some common misspellings, and terms that are used interchangeably in the organization. Search application administrators can see some of these issues when they review query reports.
Additional Reading
For more information about managing thesaurus files, see http://go.microsoft.com/fwlink/?LinkID=200899&clcid=0x409.
9-51
Lab: Designing an Enterprise Search Strategy
Exercise 1: Planning for Search

Scenario
Contoso, Ltd has decided to take advantage of the SharePoint 2010 search technology and is planning to replace the existing search solution. Contoso, Ltd wants to enable employees to find information based on keyword searches. Sources of information include file shares, documents, and other content that is stored within SharePoint; people; and the Contoso, Ltd product catalog, which exists in a SQL Server database. Your team must design the enterprise search architecture and search topology for Contoso, Ltd. In addition, your team must enable People Search. The information that your team needs is detailed in the supplied documents. Use these documents to produce your search design. The main tasks for this exercise are as follows: 1. Read the supporting information.
9-52
2. 3. 4. 5. 6.
Update the Logical Architecture Planning worksheet. Update the SharePoint 2010 Service Applications Planning worksheet. Update the Physical Architecture Planning worksheet. Update the SharePoint 2010 Security Planning worksheet. Complete the Search Planning worksheet.

1. 2. 3. Read the lab scenario. Log on to 10231A-NYC-DC1-09 as CONTOSO\Ed with the password Pa$$w0rd. In the E:\Labfiles\Lab09\Starter folder, read the information in the Contoso Search Requirements.docx file.
Task 2: Update the Logical Architecture Planning worksheet

1. 2. Open the Logical Architecture Planning Worksheet.xlsx file. Update the information for the search site.
Task 3: Update the SharePoint 2010 Service Applications Planning

worksheet
1. 2. Open the SharePoint 2010 Service Applications Planning Worksheet.xlsx file. Update the information for the search service.
Task 4: Update the Physical Architecture Planning worksheet

1. 2. Open the Physical Architecture Planning Worksheet.xlsx file. Update the information for the production and staging environments.
Task 5: Update the SharePoint 2010 Security Planning worksheet

1. 2. Open the SharePoint 2010 Security Planning Worksheet.xlsx file. Update the information for the service accounts required.
9-53
Task 6: Complete the SharePoint 2010 Search Planning worksheet

1. 2. Open the SharePoint 2010 Search Planning Worksheet.xlsx file. Add details of any content sources required.
Exercise 2: Planning Physical Topology

Scenario
Now that your search design is complete and you have updated the physical architecture, you must update the physical topology. The main task for this exercise is to plan the physical topology for search.
Task 1: Plan the physical topology for search

1. 2. 3. 4. In the E:\Labfiles\Lab09\Starter folder, read the information in the Physical Architecture Planning Worksheet.xlsx file. Open and review the Physical Architecture Diagram.vsd file. Update the diagram to include search server requirements. Close all windows.
Exercise 3: Creating Search Service Applications

Scenario
Now that the planning requirements are complete, you should implement search in the test farm by creating a search service application. The main tasks for this exercise are as follows: 1. 2. Create the search service application. Ensure that the SharePoint Server Search service is started.
Task 1: Create the search service application

1. In SharePoint Central Administration, create a new search service application with the following settings: Search Service Account: CONTOSO\sp-serviceapp-search
9-54
Search Admin Web Service application pool: Existing application pool called SearchAdminAppPool Search Query and Site Settings Web Service application pool: Existing application pool called SearchQueryAppPool
Task 2: Ensure that the SharePoint Server Search service is started

In SharePoint Central Administration, verify that the SharePoint Server Search service is started on server NYC-DC1.
Exercise 4: Configuring Search

Scenario
Now that the search service application is running in the test farm, you should configure search to crawl the relevant content sources, and perform a test search to check the results. The main tasks for this exercise are as follows: 1. 2. 3. 4. Remove people searching from the default content source, configure the crawl schedule according to your plan, and run a full crawl. Create a new content source for People Search, configure the crawl schedule according to your plan, and run a full crawl. Create a new content source for a file shares search, configure the crawl schedule according to your plan, and run a full crawl. Create an enterprise search center site collection and search for a user and a file.
Task 1: Remove people searching from the default content source,

configure the crawl schedule according to your plan, and run a full crawl
1. 2. In SharePoint Central Administration, manage the SSA. Remove the following addresses from the Local SharePoint Sites content source: http://my.contoso.com
9-55
3.
sps3://intranet.contoso.com
Create new crawl schedules for the Local SharePoint Sites content source with the following settings: Full crawl: Weekly, to start on Saturdays Incremental crawl: Repeat every 60 minutes every day
4.
Start a full crawl of the new content source.
Task 2: Create a new content source for People Search, configure the
crawl schedule according to your plan, and run a full crawl
1. In Search administration, create a new content source with the following settings: 2. Name: People Start addresses: http://my.contoso.com and sps3://my.contoso.com Full crawl schedule: Weekly, starting on Saturdays at 3 AM Incremental crawl schedule: Repeat every 60 minutes every day
Start a full crawl of the new content source.
Task 3: Create a new content source for a file shares search, configure
the crawl schedule according to your plan, and run a full crawl
1. In Search administration, create a new content source with the following settings: 2. 3. Name: File Shares Start address: \\nyc-dc1\fileshare Full crawl schedule: Monthly Incremental crawl schedule: Weekly, starting on Sundays
Start a full crawl of the new content source. Check the crawl status of the three content sources.
9-56
Task 4: Create an enterprise search center site collection and search

for a user and a file
1. Use Central Administration to create a new site collection with the following settings: 2. 3. Title: Search Center Web Site Address: http://intranet.contoso.com/sites/searchcenter Template: Enterprise Search Center Primary Site Collection Administrator: CONTOSO\Ed
Browse to the new Search Center site collection, and search for ed. Verify that the search results include the Microsoft SharePoint 2010 IT Professional Evaluation Guide and Ed Meadows.
9-57
Review Questions
1. 2. 3. 4. 5. What is the recommended maximum number of items for a single SharePoint search index partition? What is the recommended maximum index size for SharePoint search? What factors affect index size? Who can add best bets to improve search functionality? What do you need to add to SharePoint search to index new file types?
Best Practices Related to Planning Search for SharePoint 2010

Supplement or modify the following best practices for your own work situations: Carefully plan storage requirements for all of the search components.
9-58
Pilot the farm and test crawl and query performance with a significant test dataset. Using too small a dataset can skew the results. Establish the business requirements for how fresh the index should be on an ongoing basis, and how long is acceptable for queries to be returned. Carefully plan search administration users. These users can have a significant impact on the usability of search, but administrators must take ownership of aspects such as best bets and keywords to make the most of search.

Designing A Microsoft Sharepoint 2010 Infrastructure Vol1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Designing A Microsoft Sharepoint 2010 Infrastructure Vol1

Uploaded by

Copyright:

Available Formats

MCT USE ONLY.

STUDENT USE PROHIBITED

Designing a Microsoft SharePoint 2010 Infrastructure

MCT USE ONLY. STUDENT USE PROHIBITED

Designing a Microsoft SharePoint 2010 Infrastructure

MCT USE ONLY. STUDENT USE PROHIBITED

Product Number: 10231A Part Number: 06623 Released: 09/2010

5. ADDITIONAL LICENSING REQUIREMENTS AND/OR USE RIGHTS.

Sincerely, Microsoft Learning www.microsoft.com/learning

Designing a Microsoft SharePoint 2010 Infrastructure

MCT USE ONLY. STUDENT USE PROHIBITED

John Devaney Content Developer

James Hamilton-Adams Content Developer

Rose Malcolm Content Developer

Steve Ryan Content Developer

Designing a Microsoft SharePoint 2010 Infrastructure

MCT USE ONLY. STUDENT USE PROHIBITED

Scott Jamison - Subject Matter Expert

Donal Conlon - Subject Matter Expert

Peter Serzo Technical Reviewer

Designing a Microsoft SharePoint 2010 Infrastructure

MCT USE ONLY. STUDENT USE PROHIBITED

Module 2: Planning a Service Application Architecture

Module 3: Planning for Performance and Capacity

Module 4: Designing a Physical Architecture

Designing a Microsoft SharePoint 2010 Infrastructure

MCT USE ONLY. STUDENT USE PROHIBITED

Module 5: Designing a Security Plan

Module 6: Planning Authentication

Module 7: Planning Managed Metadata

Module 8: Planning Social Computing

Module 9: Designing an Enterprise Search Strategy

Designing a Microsoft SharePoint 2010 Infrastructure

MCT USE ONLY. STUDENT USE PROHIBITED

Module 10: Planning Enterprise Content Management

Module 11: Planning a SharePoint 2010 Implementation of a Business Intelligence Strategy

Module 12: Developing a Plan for Governance

Module 13: Designing a Maintenance and Monitoring Plan

Designing a Microsoft SharePoint 2010 Infrastructure

MCT USE ONLY. STUDENT USE PROHIBITED

Module 14: Planning Business Continuity

Module 15: Planning for Upgrading to SharePoint 2010

Appendix: Lab Answer Keys

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED

Virtual Machine Environment

Virtual Machine Configuration

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED