20331B ENU TrainerHandbook

M I C R O S O F T
20331B
L E A R N I N G
P R O D U C T
MCT USE ONLY. STUDENT USE PROHIBITED
O F F I C I A L
Core Solutions of Microsoft SharePoint

Server 2013
ii Core Solutions of Microsoft SharePoint Server 2013
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.
2013 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 trademarks are property of their respective owners
Product Number: 20331B

Part Number (if applicable): X18-76951
Released: 06/2013
MICROSOFT LICENSE TERMS

MICROSOFT INSTRUCTOR-LED COURSEWARE
These license terms are an agreement between Microsoft Corporation (or based on where you live, one of its
affiliates) and you. Please read them. They apply to your use of the content accompanying this agreement which
includes the media on which you received it, if any. These license terms also apply to Trainer Content and any
updates and supplements for the Licensed Content unless other terms accompany those items. If so, those terms
apply.
BY ACCESSING, DOWNLOADING OR USING THE LICENSED CONTENT, YOU ACCEPT THESE TERMS.
IF YOU DO NOT ACCEPT THEM, DO NOT ACCESS, DOWNLOAD OR USE THE LICENSED CONTENT.
If you comply with these license terms, you have the rights below for each license you acquire.
1.
DEFINITIONS.
a. Authorized Learning Center means a Microsoft IT Academy Program Member, Microsoft Learning
Competency Member, or such other entity as Microsoft may designate from time to time.
b. Authorized Training Session means the instructor-led training class using Microsoft Instructor-Led
Courseware conducted by a Trainer at or through an Authorized Learning Center.
c.
Classroom Device means one (1) dedicated, secure computer that an Authorized Learning Center owns
or controls that is located at an Authorized Learning Centers training facilities that meets or exceeds the
hardware level specified for the particular Microsoft Instructor-Led Courseware.
d. End User means an individual who is (i) duly enrolled in and attending an Authorized Training Session
or Private Training Session, (ii) an employee of a MPN Member, or (iii) a Microsoft full-time employee.
e. Licensed Content means the content accompanying this agreement which may include the Microsoft
Instructor-Led Courseware or Trainer Content.
f.
Microsoft Certified Trainer or MCT means an individual who is (i) engaged to teach a training session
to End Users on behalf of an Authorized Learning Center or MPN Member, and (ii) currently certified as a
Microsoft Certified Trainer under the Microsoft Certification Program.
g. Microsoft Instructor-Led Courseware means the Microsoft-branded instructor-led training course that
educates IT professionals and developers on Microsoft technologies. A Microsoft Instructor-Led
Courseware title may be branded as MOC, Microsoft Dynamics or Microsoft Business Group courseware.
h. Microsoft IT Academy Program Member means an active member of the Microsoft IT Academy
Program.
i.
Microsoft Learning Competency Member means an active member of the Microsoft Partner Network
program in good standing that currently holds the Learning Competency status.
j.
MOC means the Official Microsoft Learning Product instructor-led courseware known as Microsoft
Official Course that educates IT professionals and developers on Microsoft technologies.
k.
MPN Member means an active silver or gold-level Microsoft Partner Network program member in good
standing.
l.
Personal Device means one (1) personal computer, device, workstation or other digital electronic device
that you personally own or control that meets or exceeds the hardware level specified for the particular
Microsoft Instructor-Led Courseware.
m. Private Training Session means the instructor-led training classes provided by MPN Members for
corporate customers to teach a predefined learning objective using Microsoft Instructor-Led Courseware.
These classes are not advertised or promoted to the general public and class attendance is restricted to
individuals employed by or contracted by the corporate customer.
n. Trainer means (i) an academically accredited educator engaged by a Microsoft IT Academy Program
Member to teach an Authorized Training Session, and/or (ii) a MCT.
o. Trainer Content means the trainer version of the Microsoft Instructor-Led Courseware and additional
supplemental content designated solely for Trainers use to teach a training session using the Microsoft
Instructor-Led Courseware. Trainer Content may include Microsoft PowerPoint presentations, trainer
preparation guide, train the trainer materials, Microsoft One Note packs, classroom setup guide and Prerelease course feedback form. To clarify, Trainer Content does not include any software, virtual hard
disks or virtual machines.
2.
USE RIGHTS. The Licensed Content is licensed not sold. The Licensed Content is licensed on a one copy
per user basis, such that you must acquire a license for each individual that accesses or uses the Licensed
Content.
2.1
Below are five separate sets of use rights. Only one set of rights apply to you.
a. If you are a Microsoft IT Academy Program Member:

i. Each license acquired on behalf of yourself may only be used to review one (1) copy of the Microsoft
Instructor-Led Courseware in the form provided to you. If the Microsoft Instructor-Led Courseware is
in digital format, you may install one (1) copy on up to three (3) Personal Devices. You may not
install the Microsoft Instructor-Led Courseware on a device you do not own or control.
ii. For each license you acquire on behalf of an End User or Trainer, you may either:
1. distribute one (1) hard copy version of the Microsoft Instructor-Led Courseware to one (1) End
User who is enrolled in the Authorized Training Session, and only immediately prior to the
commencement of the Authorized Training Session that is the subject matter of the Microsoft
Instructor-Led Courseware being provided, or
2. provide one (1) End User with the unique redemption code and instructions on how they can
access one (1) digital version of the Microsoft Instructor-Led Courseware, or
3. provide one (1) Trainer with the unique redemption code and instructions on how they can
access one (1) Trainer Content,
provided you comply with the following:
iii. you will only provide access to the Licensed Content to those individuals who have acquired a valid
license to the Licensed Content,
iv. you will ensure each End User attending an Authorized Training Session has their own valid licensed
copy of the Microsoft Instructor-Led Courseware that is the subject of the Authorized Training
Session,
v. you will ensure that each End User provided with the hard-copy version of the Microsoft InstructorLed Courseware will be presented with a copy of this agreement and each End User will agree that
their use of the Microsoft Instructor-Led Courseware will be subject to the terms in this agreement
prior to providing them with the Microsoft Instructor-Led Courseware. Each individual will be required
to denote their acceptance of this agreement in a manner that is enforceable under local law prior to
their accessing the Microsoft Instructor-Led Courseware,
vi. you will ensure that each Trainer teaching an Authorized Training Session has their own valid
licensed copy of the Trainer Content that is the subject of the Authorized Training Session,
vii. you will only use qualified Trainers who have in-depth knowledge of and experience with the
Microsoft technology that is the subject of the Microsoft Instructor-Led Courseware being taught for
all your Authorized Training Sessions,
viii. you will only deliver a maximum of 15 hours of training per week for each Authorized Training
Session that uses a MOC title, and
ix. you acknowledge that Trainers that are not MCTs will not have access to all of the trainer resources
for the Microsoft Instructor-Led Courseware.
b. If you are a Microsoft Learning Competency Member:

User attending the Authorized Training Session and only immediately prior to the
commencement of the Authorized Training Session that is the subject matter of the Microsoft
Instructor-Led Courseware provided, or
2. provide one (1) End User attending the Authorized Training Session with the unique redemption
code and instructions on how they can access one (1) digital version of the Microsoft InstructorLed Courseware, or
3. you will provide one (1) Trainer with the unique redemption code and instructions on how they
can access one (1) Trainer Content,
iv. you will ensure that each End User attending an Authorized Training Session has their own valid
licensed copy of the Microsoft Instructor-Led Courseware that is the subject of the Authorized
Training Session,
v. you will ensure that each End User provided with a hard-copy version of the Microsoft Instructor-Led
Courseware will be presented with a copy of this agreement and each End User will agree that their
use of the Microsoft Instructor-Led Courseware will be subject to the terms in this agreement prior to
providing them with the Microsoft Instructor-Led Courseware. Each individual will be required to
denote their acceptance of this agreement in a manner that is enforceable under local law prior to
vi. you will ensure that each Trainer teaching an Authorized Training Session has their own valid
licensed copy of the Trainer Content that is the subject of the Authorized Training Session,
vii. you will only use qualified Trainers who hold the applicable Microsoft Certification credential that is
the subject of the Microsoft Instructor-Led Courseware being taught for your Authorized Training
Sessions,
viii. you will only use qualified MCTs who also hold the applicable Microsoft Certification credential that is
the subject of the MOC title being taught for all your Authorized Training Sessions using MOC,
ix. you will only provide access to the Microsoft Instructor-Led Courseware to End Users, and
x. you will only provide access to the Trainer Content to Trainers.
c.
If you are a MPN Member:

User attending the Private Training Session, and only immediately prior to the commencement
of the Private Training Session that is the subject matter of the Microsoft Instructor-Led
Courseware being provided, or
2. provide one (1) End User who is attending the Private Training Session with the unique
redemption code and instructions on how they can access one (1) digital version of the
Microsoft Instructor-Led Courseware, or
3. you will provide one (1) Trainer who is teaching the Private Training Session with the unique
redemption code and instructions on how they can access one (1) Trainer Content,
iv. you will ensure that each End User attending an Private Training Session has their own valid licensed
copy of the Microsoft Instructor-Led Courseware that is the subject of the Private Training Session,
v. you will ensure that each End User provided with a hard copy version of the Microsoft Instructor-Led
Courseware will be presented with a copy of this agreement and each End User will agree that their
use of the Microsoft Instructor-Led Courseware will be subject to the terms in this agreement prior to
providing them with the Microsoft Instructor-Led Courseware. Each individual will be required to
denote their acceptance of this agreement in a manner that is enforceable under local law prior to
vi. you will ensure that each Trainer teaching an Private Training Session has their own valid licensed
copy of the Trainer Content that is the subject of the Private Training Session,
vii. you will only use qualified Trainers who hold the applicable Microsoft Certification credential that is
the subject of the Microsoft Instructor-Led Courseware being taught for all your Private Training
Sessions,
viii. you will only use qualified MCTs who hold the applicable Microsoft Certification credential that is the
subject of the MOC title being taught for all your Private Training Sessions using MOC,
ix. you will only provide access to the Microsoft Instructor-Led Courseware to End Users, and
x. you will only provide access to the Trainer Content to Trainers.
d. If you are an End User:

For each license you acquire, you may use the Microsoft Instructor-Led Courseware solely for your
personal training use. If the Microsoft Instructor-Led Courseware is in digital format, you may access the
Microsoft Instructor-Led Courseware online using the unique redemption code provided to you by the
training provider and install and use one (1) copy of the Microsoft Instructor-Led Courseware on up to
three (3) Personal Devices. You may also print one (1) copy of the Microsoft Instructor-Led Courseware.
You may not install the Microsoft Instructor-Led Courseware on a device you do not own or control.
e. If you are a Trainer.
i.
For each license you acquire, you may install and use one (1) copy of the Trainer Content in the
form provided to you on one (1) Personal Device solely to prepare and deliver an Authorized
Training Session or Private Training Session, and install one (1) additional copy on another Personal
Device as a backup copy, which may be used only to reinstall the Trainer Content. You may not
install or use a copy of the Trainer Content on a device you do not own or control. You may also
print one (1) copy of the Trainer Content solely to prepare for and deliver an Authorized Training
Session or Private Training Session.
ii.
You may customize the written portions of the Trainer Content that are logically associated with
instruction of a training session in accordance with the most recent version of the MCT agreement.
If you elect to exercise the foregoing rights, you agree to comply with the following: (i)
customizations may only be used for teaching Authorized Training Sessions and Private Training
Sessions, and (ii) all customizations will comply with this agreement. For clarity, any use of
customize refers only to changing the order of slides and content, and/or not using all the slides or
content, it does not mean changing or modifying any slide or content.
2.2 Separation of Components. The Licensed Content is licensed as a single unit and you may not
separate their components and install them on different devices.
2.3 Redistribution of Licensed Content. Except as expressly provided in the use rights above, you may
not distribute any Licensed Content or any portion thereof (including any permitted modifications) to any
third parties without the express written permission of Microsoft.
2.4 Third Party Programs and Services. The Licensed Content may contain third party programs or
services. These license terms will apply to your use of those third party programs or services, unless other
terms accompany those programs and services.
2.5 Additional Terms. Some Licensed Content may contain components with additional terms,
conditions, and licenses regarding its use. Any non-conflicting terms in those conditions and licenses also
apply to your use of that respective component and supplements the terms described in this agreement.
3.
LICENSED CONTENT BASED ON PRE-RELEASE TECHNOLOGY. If the Licensed Contents subject

matter is based on a pre-release version of Microsoft technology (Pre-release), then in addition to the
other provisions in this agreement, these terms also apply:
a. Pre-Release Licensed Content. This Licensed Content subject matter is on the Pre-release version of
the Microsoft technology. The technology may not work the way a final version of the technology will
and we may change the technology for the final version. We also may not release a final version.
Licensed Content based on the final version of the technology may not contain the same information as
the Licensed Content based on the Pre-release version. Microsoft is under no obligation to provide you
with any further content, including any Licensed Content based on the final version of the technology.
b. Feedback. If you agree to give feedback about the Licensed Content to Microsoft, either directly or
through its third party designee, you give to 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, Microsoft product, or service that includes the feedback. You
will not give feedback that is subject to a license that requires Microsoft to license its software,
technologies, or products to third parties because we include your feedback in them. These rights
survive this agreement.
c.
Pre-release Term. If you are an Microsoft IT Academy Program Member, Microsoft Learning
Competency Member, MPN Member or Trainer, you will cease using all copies of the Licensed Content on
the Pre-release technology upon (i) the date which Microsoft informs you is the end date for using the
Licensed Content on the Pre-release technology, or (ii) sixty (60) days after the commercial release of the
technology that is the subject of the Licensed Content, whichever is earliest (Pre-release term).
Upon expiration or termination of the Pre-release term, you will irretrievably delete and destroy all copies
of the Licensed Content in your possession or under your control.
4.
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
allows you to use it in certain ways. Except as expressly permitted in this agreement, you may not:
access or allow any individual to access the Licensed Content if they have not acquired a valid license
for the Licensed Content,
alter, remove or obscure any copyright or other protective notices (including watermarks), branding
or identifications contained in the Licensed Content,
modify or create a derivative work of any Licensed Content,
publicly display, or make the Licensed Content available for others to access or use,
copy, print, install, sell, publish, transmit, lend, adapt, reuse, link to or post, make available or
distribute the Licensed Content to any third party,
work around any technical limitations in the Licensed Content, or
reverse engineer, decompile, remove or otherwise thwart any protections or disassemble the
Licensed Content except and only to the extent that applicable law expressly permits, despite this
limitation.
5. RESERVATION OF RIGHTS AND OWNERSHIP. Microsoft reserves all rights not expressly granted to
you in this agreement. The Licensed Content is protected by copyright and other intellectual property laws
and treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property rights in the
Licensed Content.
6.
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.
7.
SUPPORT SERVICES. Because the Licensed Content is as is, we may not provide support services for it.
8.
TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you fail
to comply with the terms and conditions of this agreement. Upon termination of this agreement for any
reason, you will immediately stop all use of and delete and destroy all copies of the Licensed Content in
your possession or under your control.
9.
LINKS TO THIRD PARTY SITES. You may link to third party sites through the use of the Licensed
Content. The third party sites are not under the control of Microsoft, and Microsoft is not responsible for
the contents of any third party sites, any links contained in third party sites, or any changes or updates to
third party sites. Microsoft is not responsible for webcasting or any other form of transmission received
from any third party sites. Microsoft is providing these links to third party sites to you only as a
convenience, and the inclusion of any link does not imply an endorsement by Microsoft of the third party
site.
10.
ENTIRE AGREEMENT. This agreement, and any additional terms for the Trainer Content, updates and
supplements are the entire agreement for the Licensed Content, updates and supplements.
11.
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.
12.
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.
13.
DISCLAIMER OF WARRANTY. THE LICENSED CONTENT IS LICENSED "AS-IS" AND "AS

AVAILABLE." YOU BEAR THE RISK OF USING IT. MICROSOFT AND ITS RESPECTIVE
AFFILIATES 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 AND
ITS RESPECTIVE AFFILIATES EXCLUDES ANY IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
14.
LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. YOU CAN RECOVER FROM
MICROSOFT, ITS RESPECTIVE AFFILIATES AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP
TO US$5.00. YOU CANNOT RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL,
LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES.
This limitation applies to

o
anything related to the Licensed Content, services, content (including code) on third party Internet
sites or third-party programs; and
o
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.
Revised September 2012
x Core Solutions of Microsoft SharePoint Server 2013
Acknowledgments
Core Solutions of Microsoft SharePoint Server 2013
xi
Microsoft Learning wants to acknowledge and thank the following for their contribution toward
developing this title. Their effort at various stages in the development has ensured that you have a good
classroom experience.
Jason Lee Content Developer
Jason Lee is a principal technologist with Content Master where he has been working with Microsoft
products and technologies for several years, specializing in SharePoint architecture and development.
Jason holds a PhD in computing and is currently MCPD and MCTS certified. You can read Jason's technical
blog at www.jrjlee.com.
James Hamilton-Adams Content Developer
James has been a trainer and consultant on Microsoft Technologies for over 10 years, and is an associate
technologist with CM Group. James specializes in SharePoint Server and Exchange Server, for which he
holds MCITP and MCSE certifications, in addition to working with other platforms, such as Project Server
and Lync. James has been working with SharePoint since the first release in 2001, and regularly works with
organizations to integrate SharePoint with their business processes.
John Devaney Content Developer
John Devaney is a principal technologist with Content Master and has worked with SharePoint products
and technologies since SharePoint Portal Server 2003. He worked on both Microsoft Office SharePoint
Server 2007 and SharePoint Server 2010 MOC curriculum for IT Pros. He is a SharePoint Server 2010
MCITP and has worked as an MCT.
Mike Sumsion Content Developer
Mike Sumsion is a senior technologist with Content Master, where he has worked with a range of
Microsoft technologies. Mike has worked with SharePoint products since Microsoft Office SharePoint
Server 2007, and has produced a variety of courseware, hands-on-labs, and other documentation. Michael
has an honors degree in Computer Science, and is currently MCTS certified. You can read Mike's blog at
www.mikesumsion.com.
Stephen Ryan Content Developer
Steve Ryan is a senior technologist in the Content Master IT Pro team with over 12 years experience in
training and technical authoring. He specializes in Windows Server operating systems and SharePoint, for
which he has MCITP, MCSE, and MCTS certifications.
Scott Jamison Technical Reviewer
Scott Jamison is Chief Architect and CEO at Jornata and SharePoint subject matter expert. Scott is a
recognized thought leader and published author with several books, hundreds of magazine articles, and
regular speaking engagements at events around the globe. Scott was one of the first professionals to hold
the Microsoft Certified Master for SharePoint certification and is currently both a SharePoint MVP and
Microsoft Certified Architect for SharePoint. You can follow Scott on Twitter via @sjam and at
www.scottjamison.com.
Contents
Module 1: Introducing SharePoint 2013
Lesson 1: Key Components of a SharePoint Deployment
Lesson 2: New Features in SharePoint 2013
Lesson 3: SharePoint 2013 Deployment Options
page 2
page 7
page 13
Module 2: Designing an Information Architecture

Lesson 1: Identifying Business Requirements
Lesson 2: Understanding Business Requirements
Lesson 3: Organizing Information in SharePoint 2013
Lab A: Creating and Information Architecture Part One
Lesson 3: Planning for Discoverability
Lab B: Creating and Information Architecture Part Two
page 2
page 9
page 18
page 26
page 28
page 33
Module 3: Designing a Logical Architecture

Lesson 1: Overview of SharePoint 2013 Logical Architecture
Lesson 2: Documenting Your Logical Architecture
Lab: Designing a Logical Architecture
page 2
page 6
page 13
Module 4: Designing a Physical Architecture

Lesson 1: Designing Physical Components for SharePoint
Deployments
Lesson 2: Designing Supporting Components for SharePoint
Deployments
Lesson 3: SharePoint Farm Topologies
Lesson 4: Mapping a Logical Architecture Design to a Physical
Architecture Design
Lab: Designing a Physical Architecture
page 2
page 11
page 15
page 21
page 25
Module 5: Installing and Configuring SharePoint Server 2013

Lesson 1: Installing SharePoint Server 2013
Lab A: Deploying and Configuring SharePoint Server 2013 Part One
Lesson 2: Scripting Installation and Configuration
Lesson 3: Configuring SharePoint Server 2013 Farm Settings
Lab B: Deploying and Configuring SharePoint Server 2013 Part Two
page 2
page 16
page 19
page 24
page 33
Module 6: Creating Web Applications and Site Collections

Lesson 1: Creating Web Applications
Lesson 2: Configuring Web Applications
Lab A: Creating and Configuring Web Applications
Lesson 3: Creating and Configuring Site Collections
page 2
page 12
page 24
page 29
xii Core Solutions of Microsoft SharePoint Server 2013
Lab B: Creating and Configuring Site Collections
page 38
Module 7: Planning and Configuring Service Applications

Lesson 1: Introduction to Service Application Architecture
Lesson 2: Creating and Configuring Service Applications
Lab: Planning and Configuring Service Applications
page 2
page 11
page 19
Module 8: Managing Users and Permissions

Lesson 1: Authorization in SharePoint 2013
Lab A: Managing Users and Groups
Lesson 2: Managing Access to Content
Lab B: Securing Content in SharePoint Sites
page 2
page 12
page 19
page 28
Module 9: Configuring Authentication for SharePoint 2013

Lesson 1: Overview of Authentication
Lesson 2: Configuring Federated Authentication
Lesson 3: Configuring Sever-to-Server Authentication
Lab: Configuring SharePoint 2013 to Use Federated Identities
page 2
page 16
page 27
page 35
Module 10: Securing a SharePoint 2013 Deployment

Lesson 1: Securing the Platform
Lab A: Hardening a SharePoint 2013 Server Farm
Lesson 2: Configuring Farm-Level Security
Lab B: Configuring Farm-Level Security
page 2
page 10
page 13
page 24
Module 11: Managing Taxonomy

Lesson 1: Managing Content Types
Lab A: Configuring Content Type Propagation
Lesson 2: Understanding Term Stores and Term Sets
Lesson 3: Managing Term Stores and Term Sets
Lab B: Configuring and Using Managed Metadata Term Sets
page 2
page 7
page 11
page 15
page 20
Module 12: Configuring User Profiles

Lesson 1: Configuring the User Profile Service Application
Lab A: Configuring User Profiles
Lesson 2: Managing User Profiles and Audiences
Lab B: Configuring My Sites and Audiences
page 2
page 9
page 13
page 17
Module 13: Configuring Enterprise Search

Lesson 1: Understanding the Search Service Architecture
Lesson 2: Configuring Enterprise Search
Lab A: Configuring Enterprise Search
Lesson 3: Managing Enterprise Search
page 2
page 13
page 20
page 26
xiii
Lab B: Configuring the Search Experience
page 35
Module 14: Monitoring and Maintaining a SharePoint 2013 Environment

Lesson 1: Monitoring a SharePoint 2013 Environment
Lab A: Monitoring a SharePoint 2013 Deployment
Lesson 2: Tuning and Optimizing a SharePoint 2013 Environment
Lesson 3: Planning and Configuring Caching
Lesson 4: Troubleshooting a SharePoint 2013 Environment
Lab B: Investigating Page Load Times
page 2
page 12
page 16
page 30
page 37
page 45
Lab Answer Keys

Module 2 Lab A: Creating an Information Architecture Part One
Module 2 Lab B: Creating an Information Architecture Part Two
Module 3 Lab: Designing a Logical Architecture
Module 4 Lab: Designing a Physical Architecture
Module 5 Lab A: Deploying and Configuring SharePoint Server 2013
Part One
Module 5 Lab B: Deploying and Configuring SharePoint Server 2013
Part Two
Module 6 Lab A: Creating and Configuring Web Applications
Module 6 Lab B: Creating and Configuring Site Collections
Module 7 Lab: Planning and Configuring Service Applications
Module 8 Lab A: Managing Users and Groups
Module 8 Lab B: Securing Content in SharePoint Sites
Module 9 Lab: Configuring SharePoint to Use Federated Identities
Module 10 Lab A: Hardening a SharePoint 2013 Sever Farm
Module 10 Lab B: Configuring Farm Level Security
Module 11 Lab A: Configuring Content Type Propagation
Module 11 Lab B: Configuring and Using Managed Metadata Term
Sets
Module 12 Lab A: Configuring User Profiles
Module 12 Lab B: Configuring My Sites and Audiences
Module 13 Lab A: Configuring Enterprise Search
Module 13 Lab B: Configuring the Search Experience
Module 14 Lab A: Monitoring a SharePoint 2013 Deployment
Module 14 Lab B: Investigating Page Load Times
page 1
page 1
page 1
page 1
page 1
page 3
page 1
page 6
page 1
page 1
page 7
page 1
page 1
page 5
page 1
page 6
page 1
page 5
page 1
page 8
page 1
page 5
xiv Core Solutions of Microsoft SharePoint Server 2013
About This Course
This section provides a brief description of the course, audience, suggested prerequisites, and course
objectives.
Course Description
Note: This Second release (B) MOC version of course 20331 has been developed on RTM
software.
About This Course
This course provides an introduction to planning, deploying, configuring, maintaining, and tuning a
SharePoint 2013 farm. Students will learn how to plan a SharePoint deployment, including the
information, logical, and physical architectures. Students will also learn how to deploy a SharePoint farm,
and then how to monitor and tune a farm after deployment.
Audience
The course is targeted at experienced IT Professionals interested in learning how to install, configure,
deploy and manage SharePoint Server 2013 installations in either the data center or the cloud.
Students typically have more than four years of hands-on experience* planning and maintaining
SharePoint and other core technologies upon which SharePoint depends, including Windows Server 2008
R2 or later, Internet Information Services (IIS), SQL Server 2008 R2 or later, Active Directory, and
networking infrastructure services.
The minimally qualified candidate typically:
Is an IT professional who plans, implements, and maintains a multi-server deployment of SharePoint

Server 2013.
Has a working knowledge of, and preferably hands-on experience, with SharePoint Online.
Has broad familiarity with SharePoint workloads.
Have experience with business continuity management, including data backup, restoration, and high
availability.
Has experience with authentication and security technologies
Has experience with Windows PowerShell.
* Hands-on experience or job experience is considered a solutions-based role where the candidate works
within the solutions space covered by SharePoint, working on multiple solutions in the SharePoint space
that includes document management, content management, and search.
Student Prerequisites
An ideal candidate will have at least one year of experience with deploying and administering multiple
SharePoint 2010 farms across a large enterprise. Because many customers skipped upgrading from
SharePoint 2007, a candidate can also have at least 2 years of experience with SharePoint 2007 and
knowledge of the differences between 2007 and 2010, particularly the Service Application model.
A candidate can demonstrate the following skills:
Software management in a Windows 2008 R2 enterprise server or Windows Server 2012 environment.
About This Course
Deploying and managing applications natively, virtually and in the cloud.
Administering Internet Information Services (IIS).
Configuring Active Directory for use in authentication, authorization and as a user store.
Managing an application remotely using Windows PowerShell 2.0.
Connecting applications to Microsoft SQL Server.
Implementing Claims-based Security.
Course Objectives
After completing this course, students will be able to:
Describe the key features of SharePoint 2013.
Design an information architecture for a SharePoint 2013 deployment.
Design a logical architecture for a SharePoint 2013 deployment.
Design the physical architecture for a SharePoint 2013 deployment.
Install and configure SharePoint Server 2013.
Create and configure web applications and site collections.
Plan and configure service applications for a SharePoint 2013 deployment.
Configure authentication in a SharePoint 2013 deployment.
Configure platform and farm-level security in a SharePoint 2013 deployment.
Manage information taxonomy in SharePoint web applications and site collections.
Configure and manage user profiles and audiences.
Configure and manage the search experience.
Maintain and troubleshoot a SharePoint 2013 deployment.
Course Outline
The course outline is as follows:
Module 1, Introducing SharePoint 2013"
Module 2, Designing an Information Architecture"
Module 3, Designing a Logical Architecture"
Module 4, Designing a Physical Architecture"
Module 5, Installing and Configuring SharePoint Server 2013"
Module 6, Creating Web Applications and Site Collections"
Module 7, Planning and Configuring Service Applications"
Module 8, Managing Users and Permissions"
Module 9, Configuring Authentication for SharePoint 2013"
Module 10, Securing a SharePoint 2013 Deployment"
Module 11, Managing Taxonomy"
ii
Module 12, Configuring User Profiles"

Module 13, Configuring Enterprise Search"
Module 14, Monitoring and Maintaining a SharePoint 2013 Environment"
Course Materials
The following materials are included with your kit:
Course Handbook: a succinct classroom learning guide that provides the critical technical
information in a crisp, tightly-focused format, which is essential for an effective in-class learning
experience.
About This Course
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 on-the-job reference material to boost knowledge
and skills retention.
Lab Answer Keys: provide step-by-step lab solution guidance.
Course Companion Content: searchable, easy-to-browse digital content with integrated premium
online resources that supplement the Course Handbook.
Modules: include companion content, such as questions and answers, detailed demo steps and
additional reading links, for each lesson. Additionally, they include Lab Review questions and
answers and Module Reviews and Takeaways sections, which contain the review questions and
answers, best practices, common issues and troubleshooting tips with answers, and real-world
issues and scenarios with answers.
Resources: include well-categorized additional resources that give you immediate access to the
most current premium content on TechNet, MSDN, or Microsoft Press.
Student Course files: includes the Allfiles.exe, a self-extracting executable file that contains all
required files for the labs and demonstrations.
iii
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.
To provide additional comments or feedback on the course, send an email to

[email protected]. To inquire about the Microsoft Certification Program, send an
email to [email protected].
About This Course
Virtual Machine Environment
iv
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 Microsoft Hyper-V to perform the labs.
The following table shows the role of each virtual machine that is used in this course:
Virtual machine
Role
NYC-CL1
Windows 8 client computer for running Microsoft

Office applications.
NYC-DC1
Windows Server 2012 server acting as the domain

controller for the contoso.com domain.
NYC-DB1
Windows Server 2012 server running Microsoft

SQL Server 2012, a member of the contoso.com
domain.
NYC-SP1

SharePoint Server 2013, a member of the
contoso.com domain.
NYC-OWA1

Office Web Apps, a member of the contoso.com
domain.
SEA_ADFS1
Windows Server 2012 server, acting as the domain

controller for the contosoresearch.net domain, and
running Active Directory Federation Services.
Software Configuration
The following software is installed on each VM:
Microsoft Windows 8 Enterprise
Microsoft Office 2013
Microsoft Visio Professional 2013
Microsoft Windows Server 2012
Microsoft SharePoint Server 2013
Microsoft Office Web Apps
Course Files
The files associated with the labs in this course are located in the E:\ModXX\ folder on the student
computers.
Classroom Setup
Each classroom computer will have the same virtual machine configured in the same way.
Course Hardware Level
About This Course
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 is taught.
Hardware Level 7
64 bit Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) processor
(2.8 Ghz dual core or better recommended)
Dual 500 GB hard disks 7200 RPM SATA or faster (striped).
16GB RAM.
DVD drive (dual layer recommended)
Network adapter with Internet connectivity
Dual SVGA monitors 17 or larger supporting 1440X900 minimum resolution
Video adapter that supports 1440 x 900 resolution
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 x 768 pixels, 16 bit colors.

1-1
Module 1
Introducing SharePoint Server 2013
Contents:
Module Overview
1-1
Lesson 1: Key Components of a SharePoint Deployment
1-2
Lesson 2: New Features in SharePoint 2013
1-7
Lesson 3: SharePoint 2013 Deployment Options
1-13
Module Review and Takeaways
1-16
Module Overview
Microsoft SharePoint Server 2013 is a document storage and collaboration platform that offers many
benefits to organizations. SharePoint deployments may take many different forms in scope, where a
deployment may be focused on only delivering one feature, such as enterprise search, or many features,
such as document management, business intelligence, web content management, and workflows.
Deployments can also differ greatly in size, with small deployments of a single server up to large
deployments with farms of 15 or more servers.
In this module, you will learn about the core features of SharePoint 2013, the new features in this version,
and what has been removed. You will also learn about the basic structural elements of a farm deployment
and how they fit together. Finally you will learn about the different deployment options available to
SharePoint 2013.
Objectives
After completing this module, you will be able to:
Identify the capabilities and architecture of SharePoint 2013.
Identify new and deprecated features in SharePoint 2013.
Identify deployment options for SharePoint 2013.
Lesson 1
Key Components of a SharePoint Deployment
1-2
SharePoint 2013, like previous versions of SharePoint, has a wide range of features and capabilities even
without adding third-party tools or solutions. It is important to understand how organizations can use
these features to provide productivity improvements, more robust working practices, or support
compliance requirements. After identifying key feature requirements, you should also make
considerations for what logical structure components are required to support specific features and how
these interact with the farm. A critical element for most SharePoint deployments is how will you support
your information architecture requirements, making it easier for users to find, work with, and update
content in the SharePoint environment.
In this lesson, you will review SharePoint capabilities, logical architecture, and information architecture.
Lesson Objectives
After completing this lesson, you will be able to:
Identify key areas of SharePoint experience.
Describe the capabilities of a SharePoint environment.
Describe the logical architecture of a SharePoint deployment.
Describe the SharePoint 2013 features that support information architecture.
Discussion: Identifying SharePoint Experience

A SharePoint farm is made up of many
components. To understand any previous
experience of SharePoint administration you may
have, discuss the following questions:
Have you previously deployed a SharePoint

farm?
Have you previously administered a

SharePoint farm?
Have you previously created a new service

application?
Have you previously added new site

collections to a farm?
Have you previously administered a site collection or site?
Overview of SharePoint Capabilities

SharePoint 2013 is a platform that offers a diverse
range of capabilities. Organizations may choose to
implement some or all of these capabilities to
achieve productivity improvements, present
information in new ways, or enable new ways of
working.
You can group the capabilities of SharePoint 2013
into the following categories:
1-3
Collaboration. SharePoint provides the ability

to collaborate on different types of content,
such as documents, web content, list items,
media content, and drawings. Collaboration
can be asynchronous and controlled by check-out and check-in functions, or in some cases,
collaboration can be synchronous so that more than one person can be working on a document at
the same time.
Enterprise Content Management (ECM). ECM is best described as a formal means of storing and
organizing data, documents, and other content within an organization. SharePoint provides specific
features to support ECM functionality, including item versioning and approval, records management,
workflows, content lists and libraries, and managed metadata.
Web Content Management (WCM). WCM extends some of the ECM functionality into web content
capabilities, such as version control, content approval and publishing, content deployment, cross-site
publishing, managed navigation, and device-specific targeting.
Social computing. Social computing in SharePoint 2013 enables users to keep informed about tasks or
content that colleagues are working with. Social computing can also enable employees from different
locations or departments to link up and easily share information, perhaps when working on the same
project. SharePoint 2013 also provides SkyDrive for storing and sharing content and provides
community sites as a basis for discussion forums around specific subject areas. SkyDrive was labeled
My Sites in previous versions of SharePoint.
Search. The search capability in SharePoint 2013 provides the capability to index content stored in
SharePoint, such as webpages, list items, and document content. In addition, it can index content held
in other repositories, such as file shares, other websites, Exchange Server, and external databases. In
this way, it can provide users with an easy way to find specific content from large data stores, provide
metadata-based refinement capabilities, and provide search administrators with the ability to
promote certain content where appropriate.
Business intelligence (BI). Business intelligence in SharePoint 2013 provides organizations with the
ability to analyze business data in many different ways. BI features include the ability to display
updated chart information, key performance indicators (KPIs), dashboards, and data-driven Visio
diagrams directly on a page. Tools such as PowerPivot can give users the ability to process data from
billions of rows, and SQL Server Reporting Services integration provides the ability to create libraries
of reports to match management requirements.
Composites. In SharePoint 2013, a composite refers to the capabilities of a SharePoint site to deliver a
mix of content based on the user or business requirement. A SharePoint site may include some
spreadsheets, a chart published to a webpage, external data integrated into a SharePoint list, a datadriven Visio diagram, and some workflow elements to represent a business process. Composites
leverage SharePoint 2013 features, such as workflows, Excel services, Visio services, Business
1-4
Connectivity Services (BCS), InfoPath Forms services, and Access services to deliver highly specialized
functionality with the potential for zero-code customizations by using built-in tools.
Overview of SharePoint Logical Architecture

The logical structure of SharePoint 2013 is made
up from the following components:
Farm. A SharePoint farm runs on one or more

servers and typically consists of several web
applications and service applications. The farm
configuration database stores the web
application details and the service application
associations within the farm, and there is only
one farm configuration database per farm.
Service applications. Service applications

provide specific functionality to web
applications within the farm, such as search,
Excel services, or Managed Metadata. Administrators create and configure service applications at the
farm level, but it is possible to associate one or more service applications with only specific web
applications to control which web applications can use specific functions or features. Service
applications are connected to web applications through a service application proxy or application
proxy group. Each service application represents some managed code in SharePoint being run by an
application pool in Internet Information Services (IIS).
Web applications. A web application in SharePoint can hold one or more site collections in one or
more databases, which run under a common server name or IIS host header, such as
http://sharepoint.litwareinc.com. A web application may have more than one host header, which can
be supported by more than one Alternate Access Mapping (AAM). All site collections within a web
application can only use the AAMs configured at the parent web application. Web applications also
provide the link to the corresponding web site object in IIS, and a link to specific content databases in
SQL Server for the storage of site collections and associated content. Each web application also
requires a folder in the IIS file structure of each Web Front End (WFE) server to store associated code,
solutions, templates, and web configuration files.
Content database. Each content database runs on SQL Server, and holds the content from one or
more site collections. A content database can only be associated with one web application at a time.
Site collection. A site collection is made up of one or more SharePoint sites that are organized as a
hierarchy within the site collection. When you create a new site collection, a special site known as a
top-level site is created within the site collection. The top-level site is the highest site in the hierarchy
of that particular site collection, and it has the shortest URL of all sites within that site collection. In
addition, some site collection settings are only accessible from the top-level site settings page.
Although all site collections in the same web application typically share the same AAM, there is no
hierarchy between site collectionsone site collection does not inherit security, navigation, or other
settings from another site collection (although two site collections may have some settings the same
when controlled by a service application). This means that each site collection behaves as a security
boundary. For example, although a site collection at http://sharepoint.litwareinc.com/sites/hr appears
to be below the site collection at http://sharepoint.litwareinc.com/ (because of the similar but longer
URL), the first site collection does not inherit any settings from the second.
Site. SharePoint sites are created as part of a hierarchical structure within a site collection, starting
with the top-level site. When you create a new site, the site structure and layout will be based on a
1-5
predefined site template, which is usually based on the type of use the site is expected to receive,
such as collaboration, document storage, or business intelligence. In some respects, you should
consider SharePoint sites as analogous to folders in a network file sharefolders on a network file
share are often used to organize content that has a similar purpose or use, such as for a department
or project. In a similar way, in SharePoint, organizations can use sites to organize content, such as
creating a site for a department or a site for a project. Sites can contain more than simply files,
because you can have lists, workflow, web page content, or other types of information to provide a
richer and smarter experience for users. Sites can inherit settings, such as permissions and navigation
behavior, from a parent site. Typically, sites contain one or more lists or libraries, which a site uses to
organize and store the site content.
Overview of Information Architecture in SharePoint 2013

When planning a SharePoint 2013 deployment,
you should spend some time planning how you
will classify and categorize information that is
stored in SharePoint lists and libraries. This
categorization and classification forms a large part
of your information architecture and is a crucial
part of assisting users in finding the information
needed to perform work efficiently.
SharePoint refers to the information used to
categorize and classify content as metadata.
Metadata in SharePoint can hold a variety of
different categories or classifications, such as
departments, locations, projects, or any other suitable criteria.
SharePoint uses the following features to support the use of metadata as part of an organizations
information architecture:
Site columns. You can create site columns at the site level to hold metadata as an additional column
that can be applied to a list or library within or below that site in the hierarchy. Site columns can use a
variety of types, such as text, choice, number, date and time, person or group, or calculated. Creating
a site column at a top-level site makes that column available to all lists and libraries in the site
collection; however, site columns cannot be inherited from one site collection to another.
Managed Metadata. The Managed Metadata service in SharePoint enables you to create term sets to
use as metadata in lists and libraries. Terms sets represent metadata categories or classifications with
a defined number of terms that can be applied as metadata to items in SharePoint lists or libraries.
Because Managed Metadata is a service application in SharePoint, you can create global term sets
that users can apply within any site collection of the farm. For users to apply terms from a term set, a
list, library, or site column should be created that specifies the Managed Metadata term set as the
source. In addition, in SharePoint 2013 you can use Managed Metadata term sets for site navigation.
Content types. You use content types to define a type of item or document, such as a business plan or
a budget statement. Content types behave as a special kind of template that can have a file template,
site columns, workflow and information management policy settings defined. This means that
wherever you use that content type, there will be a standard requirement for content and metadata.
Like site columns, content types are managed at the site collection level.
Document sets. Document sets are intended to collate documents that should be dealt with together,
both from an organizing perspective and often as part of a business process, such as a set of project
documents. Document sets present a specialized folder interface to users, providing users with a
1-6
familiar structure for organizing information, but providing extended capabilities, such as the ability
to apply metadata changes to documents in the set.
Location-based metadata defaults. To help users start working with metadata and keeping a familiar
structure for organizing documents, you can enable specific folders within a document library to
apply default values to specific metadata fields or columns.
Lesson 2
New Features in SharePoint 2013
1-7
SharePoint 2013 builds on the established platform of SharePoint 2010. This means that SharePoint 2013
and SharePoint 2010 share many common features and capabilities. However, SharePoint 2013 has new
features for social computing, search, business intelligence, and web content management, among others.
There are also some features that have been deprecated or removed in SharePoint 2013.
This lesson introduces many of the new features of SharePoint 2013 for administrators and end users, and
it identifies which features have been deprecated or removed.
Lesson Objectives
Describe new architectural features added to SharePoint 2013.
Describe new content management features added to SharePoint 2013.
Describe new enterprise features added to SharePoint 2013.
Describe features deprecated in SharePoint 2013.
Identify administration interface components.
Describe new interface behavior in Central Administration.
New Architectural Features for SharePoint 2013

SharePoint 2013 builds on the architecture and
management of SharePoint 2010, but it includes
many new features and functions, which can be
grouped into the following categories:
Architecture features:
o
The Request Management feature

enables administrators to create rules that
map certain types of requests to specific
servers or to a group of servers in the
farm, including prioritizing and throttling
request types.
The Application Management service forms the basis of the new application model in SharePoint
2013, providing application license, use, and permission controls.
The Machine Translation Service provides a built-in automated translation service to translate
Microsoft Office documents, HTML pages, and other SharePoint content. Translation work is
performed by submitting content to the Bing translation service on the Internet.
The Work Management service aggregates Microsoft Exchange tasks and Microsoft Project
Server tasks for a user into the SharePoint environment, providing users with a complete view of
task and work activity information.
In SharePoint 2013, Office Web Applications is a separate server solution that can be deployed
independently of an organizations SharePoint environment.
Claims authentication has been improved and is now the default option for web applications.
SharePoint 2013 relies on the new Server to Server Security Token Service (S2S STS) to
authenticate with Exchange Server and Lync Server to retrieve data from that server application.
Search features:
o
The Search service application now performs analytics tasks that were the job of the Web
Analytics service in SharePoint 2010.
The Search service now includes a continuous crawl option as an alternative to incremental
crawls.
SharePoint 2013 Search includes relevance enhancements, including promoted results defined by
query rules, result blocks showing groups of related results, and relevance adjustments to
improve result ranking.
Result sources now replace both federated locations and search scopes.
Mobile features:
o
A new view for mobile browsers that support HTML5 with automatic browser redirection to the
appropriate view.
Device channels enable page customization for specific client devices based on the user agent
string.
Note: For more information about new features in SharePoint 2013, see Explore SharePoint
2013 at http://go.microsoft.com/fwlink/?Linkid=299517
New Content Management Features in SharePoint 2013

New content management features and functions
in SharePoint 2013 can be grouped into the
following categories:
1-8
Enterprise Content Management features:

o
Team folders are a new feature designed

to link email and document content.
Team folders have an email address and
enable the receiving of email to an
Exchange Server 2013 mailbox that is
linked to the site. Related documents are
stored in a SharePoint document library.
Document sets can now include folders and OneNote notebooks. Document set versions can be
managed as a whole, and queries can show special icons for document sets.
You can use a Managed Metadata term set to drive site navigation. Term sets can also be limited
to use within specific site collections, and multilingual support for Managed Metadata has been
improved by allowing the use of locale IDs without the need for a corresponding language pack
installation.
SharePoint 2013 has a new Project Site template. This template can link with Project Server 2013
or operate independently to provide some straightforward project management tools, such as
displaying deadlines, timelines, and calendars.
Web Content Management features:
Cross-site content publishing is now available out-of-the-box by using built-in Web Parts and the
Search service. Cross-site publishing uses catalog settings to control which content is made easily
visible across different site collections.
Several improvements have been made to content authoring, including better copy and paste
from Microsoft Word to content editor and rich-text editor Web Parts. In addition, you can now
add IFrames to HTML fields.
Video file support is improved, with automatic thumbnail generation and a new video content
type.
Uploaded images can now support renditions. Renditions provide the ability to use resized
variants of the original source image to improve storage requirements and provide a better end
user experience.
There are new search-driven Web Parts that enable new queries based on catalog information,
tags, and refinements.
Rollup pages are created to assist in structuring content with the metadata navigation feature.
Rollup pages can use search Web Parts to provide a dynamic view of structure and content.
Compliance features:
o
New compliance and records management features are now available at the site level. When sites
are created, such as a project site, a policy template can be applied that defines retention policies
for items, including email messages. Retention policies can include criteria that determines when
a project closes and when a project expires.
New options, such as preservation, are available as part of in-place records management.
Preservation offers a more sophisticated alternative to holds on content that were used in
SharePoint 2010.
SharePoint 2013 offers a new site template named Discovery Center to aid eDiscovery. The
Discovery Center offers discovery cases that enable users to perform more sophisticated criteria
definition for the discovery process.
New Enterprise Features for SharePoint 2013

New enterprise features and functions in
SharePoint 2013 can be grouped into the
following categories:
1-9
Business connectivity features:

o
SharePoint can use OData-based data

sources in a similar way to Windows
Communication Foundation (WCF) and
SQL-based data sources. OData is an
open, industry standard protocol for data
exchange that is used by SQL Azure, the
Azure Data Marketplace, SQL Server
Reporting Services (SSRS), and other
third-party data sources.
1-10 Introducing SharePoint Server 2013
External list data can now be exported to an Excel workbook, where the exported data will
remain linked to the external list.
Backup domain controller (BDC) models, which form part of the BCS, can now be scoped so that,
if desired, the BDC model is only available to specific apps within the SharePoint farm.
Business intelligence features:

o
Improvements have been made to the Excel Services Web Parts in the areas of PivotTables and
PivotCharts, with an improved interface and enhanced support for SQL Server Analysis Services
(SSAS) and PowerPivot data models.
The Excel client application also supports new Excel Services functions, such as calculated
measures and calculated members functions using SSAS data, and the ability to support timeline
controls for data filtering by time period.
Visio Services now includes a Maximum Cache Size parameter to help prevent the service from
consuming excessive system resources.
Visio Services also enables users to add comments to full-page rendered drawings to enhance
collaboration.
PerformancePoint dashboards support themes and styles, and dashboards can be exported to
other sites or servers. Dashboards also support the use of the Safari browser on iPads.
PerformancePoint supports the EffectiveUserName property in SSAS, which means that

Kerberos authentication is no longer required to avoid the double-hop authentication issue,
which limited passing user credentials back to secondary servers.
Composite features:
o
Access Services now uses a separate SQL Server database for each published application.
Previously, SharePoint 2010 used a SharePoint list for each Access Services application.
Users can now use the Access 2013 client application to create rich, data-driven applications that
can then be packaged as SharePoint 2013 applications without requiring code-writing skills.
SharePoint 2013 workflow functionality is built on Windows Workflow Foundation (WF) 4, which
runs in Windows Server AppFabric (an Azure feature).
You can now switch between the declarative workflow designer in SharePoint Designer 2013 and
the graphical workflow designer in Visio 2013 as you create your SharePoint workflows.
SharePoint Designer 2013 workflows can now include workflow stages to allow more complex
workflow modeling.
Social computing features:

o
Content management and permissions within the My Site for each user has been simplified, and
only one document library is provided by default.
The microblogging capability has been significantly enhanced in SharePoint 2013. Microblogging
can now include conversations, mentions, hashtags, and following of sites or documents.
Community Sites is a new site template in SharePoint 2013 that provide enhanced forum
functionality, including moderation, categories, discussions, achievements, awards, and ratings.
Core Solutions of Microsoft SharePoint Server 2013 1-11
Demonstration: Examining SharePoint Central Administration

Demonstration Steps
Go to the Start screen. Click SharePoint 2013 Central Administration.
If a User Account Control dialog box appears, click Yes.
On the Central Administration Home page, click Application Management, on the Application
Management page, under Service Applications, click Manage service applications.
On the Manage Service Applications page, on the Service Applications tab, click New, and review
the list of available service applications. Point out new service applications, such as the Machine
Translation Service and the Work Management Service Application to students.
On the Manage Service Applications page, in the list of service applications, click Contoso Search.
You must click Contoso Search in the Search Service Application row, not the Search Service
Application Proxy row.
On the Contoso Search: Search Administration page, show the Search Application Topology
section, and show that the topology cannot be edited in the web browser.
On the Contoso Search: Search Administration page, click Central Administration.
In Central Administration, under Application Management, click Manage web applications.
On the Web Applications Management page, click SharePoint - sharepoint.contoso.com80, and

then on the ribbon, click Authentication Providers.
In the Authentication Providers dialog box, point out the authentication is set to use Claims Based
Authentication, and then click Close dialog.
On the Web Applications Management page, in the Quick Launch area, click Application
Management.
On the Application Management page, under Site Collections, click Create site collections.
On the Create Site Collection page, enter a title and URL for the site collection. Show the available
templates when the 2013 experience is selected. Show the available templates when the 2010
experience is selected.
With the 2013 experience selected, under Collaboration, click the Community Site template.
In the Primary Site Collection Administrator box, type CONTOSO\administrator, and then click
OK.
Deprecated Features in SharePoint 2013

The following features and functionality have been
changed or deprecated in SharePoint 2013:
The visual upgrade feature in SharePoint 2010

is not available in SharePoint 2013. Visual
upgrade has been replaced with the more
comprehensive deferred site collection
upgrade feature.
Several site templates have been removed

from SharePoint 2013 and cannot be used
when creating new sites, although existing
sites using these templates will still continue
to function following an upgrade. In addition,
the Visio process repository site template is deprecated, but it will still be available when creating new
sites in SharePoint 2013. The following site templates have been removed from SharePoint 2013:
o
Document Workspace site template
Personalization site template
Meeting Workspace site templates
Group Work site template
Imaging Web Services is included and supported in SharePoint 2013, but it will be removed in the
next major release of SharePoint.
Excel workbooks with external data connections in Excel Services cannot be refreshed in the browser
and must be open in the Excel client application. You can still refresh or edit in the browser
workbooks with data connections that have credentials stored in the Secure Store Service or the
connection string.
The Web Analytics service is not available in SharePoint 2013. Analytics, such as top hits and hit
counts, is now part of the Search service in SharePoint 2013.
Organization profiles are deprecated in SharePoint 2013 and will be completely removed in the next
major release of SharePoint.
The Search service topology cannot be changed by using the web interface in SharePoint 2013. In
SharePoint 2013, the Search service topology can only be modified by using Windows PowerShell.
The Search services thesaurus is now always sensitive to diacritical marks, and this feature cannot be
disabled in SharePoint 2013. This means that if a user searches for munchen, mnchen will not appear
in the search results by default.
Thesaurus replacement entries are not supported in SharePoint 2013. All thesaurus entries are now
expansion entries.
Search RSS and enterprise search from Windows 7 is deprecated in SharePoint 2013. Search Center
sites do not offer this functionality in SharePoint 2013.
SharePoint Workspace is no longer available as part of the Microsoft Office suite of products and is
replaced by SkyDrive Pro, which is a Windows client that synchronizes SharePoint documents.
Note: For more information about deprecated or removed functionality, see Changes from
SharePoint 2010 to SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299518
Lesson 3
SharePoint 2013 Deployment Options
1-13
SharePoint deployments come in many different sizes and with many different feature requirements. This
means that it is important to understand how features align in different editions of SharePoint 2013 and
which edition of SharePoint 2013 would meet the needs of a specific deployment.
This lesson introduces the different options for SharePoint 2013 deployments, including the different
editions of SharePoint 2013 for on-premises deployments, SharePoint Online deployments, and how the
two can be combined as a hybrid deployment.
Lesson Objectives
In this lesson, you will learn how to:
Describe the different editions of SharePoint 2013.
Describe a SharePoint Online deployment.
Describe a hybrid SharePoint 2013 deployment.
SharePoint 2013 Editions

There are several different editions of SharePoint
2013 that organizations can choose from for an
on-premises deployment.
SharePoint Foundation offers an entry-level or
small office SharePoint solution with minimal
costs. SharePoint Foundation includes document
management and collaboration features, search
capabilities, and a scalable architecture. SharePoint
Foundation licensing is included with Windows
Server licensing and Windows Client Access
Licenses (CALs), allowing many organizations to
leverage the benefits of SharePoint collaboration.
SharePoint Server is available in Standard and Enterprise editions. Standard edition offers Enterprise
Content Management (ECM), Web Content Management (WCM), Managed Metadata, user profile
synchronization, My Sites, audience targeting, Secure Store Service, and social networking. Enterprise
edition offers PerformancePoint, Visio Services, Access Services, Excel Services, and InfoPath Forms
Services. In SharePoint Server 2013, no CALs are required for external users accessing content in extranet
or Internet site scenarios.
SharePoint Online Deployments

SharePoint Online deployments give organizations
an additional option for how they choose to
deploy SharePoint. SharePoint Online is part of
Microsoft Office 365, but you can license only the
SharePoint Online component.
The primary advantages of a SharePoint Online
deployment include:
Management of the infrastructure and a

service level agreement (SLA) are provided as
part of the subscription, so administrators can
focus on managing other SharePoint
elements, such as site structure, permissions,
and Managed Metadata.
Organizations may also want a rich extranet capability that is easy to provision and prevents external
partners from having access to the internal corporate network.
Site customization is supported in SharePoint Online, and SharePoint Designer is able to connect to and
edit sites and workflow in the SharePoint Online environment. However, full trust coded solutions, also
known as farm level solutions, are not supported in SharePoint Online, although sandboxed code
solutions are supported and the new SharePoint App model will soon be supported.
SharePoint Online also offers Active Directory integration through the use of Active Directory Federation
Services (AD FS). This enables users to log on to the SharePoint Online environment using the same user
names and passwords that they use to access their desktop environments.
SharePoint Online offers two plans, and two levels of functionality, when combined as part of other Office
365 plans. One plan level offers standard SharePoint capabilities plus the ability to view Office documents
in the browser interface. The other plan level adds Enterprise features with full Office Web App
capabilities. SharePoint Online does not provide the following SharePoint Server capabilities:
PerformancePoint
Developer Dashboard
SharePoint timer jobs
Office client business data integration
Records Center
Word Automation Services
Business Intelligence Center
Chart Web Parts
Data connection libraries
PowerPivot for SharePoint
Federated search
Web Analytics service
Reference Links: SharePoint Online is regularly updated, so any table of feature

comparisons with SharePoint 2013 is inevitably going to become dated. For the latest description,
see SharePoint Online Service Description at http://go.microsoft.com/fwlink/?Linkid=299520
SharePoint 2013 Hybrid Deployment

With SharePoint 2013, it is possible to mix an onpremises deployment and a SharePoint Online
deployment in such a way that certain features
and functionality can be shared between the two
environments. This approach is called a hybrid
deployment.
1-15
Hybrid deployments can offer some organizations

the best of both worlds, with some content being
made available from an on-premises farm, and
some content being held in SharePoint Online.
Hybrid deployments can use single sign-on, so
that users only need to authenticate once using an
Active Directory domain user account to gain access to both on-premises SharePoint farms and
SharePoint Online. Hybrid deployments can use federated search to provide search results that
encompass both on-premises and SharePoint Online content for users of both environments, if desired.
You can also use Business Connectivity Service (BCS) functionality to directly publish certain on-premises
data to the SharePoint Online environment. This is called a SharePoint BCS Hybrid solution. SharePoint
BCS Hybrid solutions can only publish line-of-business (LOB) data from on-premises environments to
SharePoint Online, not from SharePoint Online to on-premises. Data is published securely using the onpremises BCS services to handle data connectivity, and then using a reverse proxy to publish the BCS
connection to SharePoint Online.
Note: For more information about SharePoint 2013 hybrid deployments, see Hybrid for
SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299521

Best Practice: In this module, you reviewed the capabilities and logical architecture of
SharePoint 2013, and you examined the SharePoint features that support the information
architecture for an organization.
You also examined the new features and reviewed the features deprecated for SharePoint 2013.
Finally, you looked at the options for on-premises SharePoint, SharePoint Online, and hybrid
SharePoint deployments.
Review Question(s)
Question: Why would location-based metadata defaults be particularly helpful to increase
metadata usage and help drive user adoption?
Test Your Knowledge
Question
Which of the following is a new feature in SharePoint 2013?
Select the correct answer.
PerformancePoint integration
Group Work site template
Diacritic sensitivity in the thesaurus
HTML5 view for mobile browsers
SharePoint Workspace
Verify the correctness of the statement by placing a mark in the column to the right.
Statement
True or False: A SharePoint 2013
deployment can publish data from a SQL
Server database on the internal network.
Answer

2-1
Module 2
Designing an Information Architecture
Contents:
Module Overview
2-1
Lesson 1: Identifying Business Requirements
2-2
Lesson 2: Understanding Business Requirements
2-9
Lesson 3: Organizing Information in SharePoint 2013
2-18
Lab A: Creating an Information Architecture Part One
2-26
Lesson 4: Planning for Discoverability
2-28
Lab B: Creating an Information Architecture Part Two
2-33
2-34
Module Overview
Information architecture (IA) defines the structures by which an organization catalogs information.
Designing an IA requires a detailed understanding of the information held in an organization and its
usage, context, volatility, and governance. A good IA rationalizes the creation and storage of content and
streamlines its surfacing and use.
IA design should be platform-neutral, but it must also be driven by the functionality of its environment.
Microsoft SharePoint Server 2013 provides a rich and functional platform for the development and
implementation of efficient and effective IA structures. The integral use of metadata throughout
SharePoint 2013 means that an IA designer has a range of storage, navigation, and retrieval options to
maximize usability in a well-structured IA.
In this module, you will learn about the core elements of IA design and the facilities and devices available
in SharePoint 2013 to deploy an effective information management solution.
Objectives
Explain how understanding business requirements drives the design of an organizational IA.
Describe the key components available in SharePoint 2013 to deploy an IA.
Plan for discoverability as part of an IA deployment.
Lesson 1
Identifying Business Requirements
2-2
This lesson explains why it is essential to understand your organizations business requirements when you
are planning a SharePoint 2013 deployment. You can only design a successful SharePoint 2013 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 feature-centered design for
individual components such as Search or business intelligence (BI).
Although this lesson is in the Designing Information Architecture module, it is pertinent to all planning,
whether for information, logical, physical architectures or the services and configuration of your
SharePoint 2013 deployment.
Lesson Objectives
Describe the guidelines for gathering requirements.
List approaches to requirements gathering.
Describe functional requirements.
Describe nonfunctional requirements.
Describe how to organize information.
Essentials of Requirements Gathering

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 2013 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 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 help ensure 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 it 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.
Incorporate available information architecture
Information architecture (IA) describes the structure by which you catalog and store information in an
environment. If there is a current IA in place, or an analyst is currently developing an IA, you should
ensure that you understand the impact that IA requirements may have on security boundaries and
navigation requirements.
Establishing a licensing budget
The 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 the new Office or SQL Server 2012.
Including functional and nonfunctional requirements
A good design may be one that causes the 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. Although performance is often a function of physical resources, it is
also important to ensure that the architecture does not overload physical resources. You must gather both
functional and nonfunctional information because the latter will have a major influence on your design.
Maintaining documentation
After you gather information, make sure that you document the requirements and the 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.
Avoiding technology-based design
You should not focus your design on a particular technology. Even if you are designing a SharePoint 2013
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 2013 has a range of great technical capabilities, but you should ensure that your solution is
based on business requirements, not solution features. The SharePoint 2013 features may deliver the
functionality that solves a business requirement, but your design must always put the requirement before
the feature.
Avoiding leading questions
2-4
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.
Approaches to Requirements Gathering

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:
o
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 senior stakeholders to identify the composition
of the groups so that you do not get a skewed perception of the business. Questions may include:
o
What key technology functions are required for your business division?
What benefits do you want to realize from a SharePoint 2013 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 they may have a big
influence in decision-making. Questions may include:
o
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:
o
Can we re-create or extend this functionality in SharePoint 2013?
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. Generally, you should limit meetings to one
hour, although this is 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 approve your
analysis. Make sure that your documentation reflects business language, rather than transposing business
requirements into computer jargon.
Planning for Functional Requirements

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.
2-6
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 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 2013 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 IA taxonomy that is augmented by divisionally specific taxonomies.
The administration of departmental or project websites may be a core requirement. This can affect
options such as site permissions or self-service site creation.
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 2013 for ongoing data management. You should
review any IA design documentation, because IA should reflect any regulatory requirements.
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 2013 functionality and how it maps to the business language that you
gather.
2-7
There are elements of functional and nonfunctional planning that can merge, such as authentication
versus security. It is important to not 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.
Planning for Nonfunctional Requirements

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
accordance with budget limitations. 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 have only 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.
Capacity. Your design must provide sufficient capacity over an effective hardware management
period, which is usually 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 2013 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.
2-8
Manageability. If your deployment requires self-service provisioning, you must ensure that both
administrative staff and delegated users can manage your solution.
Interoperability. SharePoint 2013 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
2013 requirements.
There is no default priority for these nonfunctional requirements. You must prioritize each one based on
the business requirements and budget of your organization. After you establish the requirements for each
one, review your results with the key stakeholders to establish the priority.
Organizing Your Information

Regardless of how carefully you record 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. Like 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 on 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 on the
nonfunctional components to ensure that the elements of your requirements that do not relate to
SharePoint 2013, such as security or network performance, are agreed.
Lesson 2
Understanding Business Requirements
2-9
Central to any IA design is a thorough understanding of the organizations business requirements, but you
also need to understand what an IA can offer an organization. There can be multiple reasons for an
organization to desire a well-structured IA, but most of these reflect dissatisfaction with the current
situation. It is important that you can convert goals into measurable success criteria to ensure that an IA
fulfills these criteria. An IA designer must identify the function and use of information across the
organization, as well as its overarching governance. The information architecture design must be
influenced by the business goals, information context, and technology platform functionality.
In this lesson, you will learn the key elements of a successful IA project.
Lesson Objectives
Describe the function of an IA.
Define the drivers of an IA project.
Describe how to initiate an IA project.
Discuss the importance of business goals.
Describe the methodologies available for IA design.
Explain the importance of people and context in structuring an IA.
Explain how SharePoint 2013 functionality will influence an IA design.
What Is Information Architecture and Why Is It Important?
Information Architecture describes the structure

by which information is cataloged and stored in an
environment. This does not just apply to
SharePoint 2013 or even to data and documents;
even your local grocery store categorizes goods so
that you can find them quickly and easily. Some
information architectures are so well known that
they are referred to by name, such as the Dewey
Decimal Classification (DDC), which is used
worldwide to catalog books in libraries. Most
people do not even think of this as an information
architecture, but imagine what it would be like to
search for a book on a topic if DDC did not exist. Libraries could catalog books based on topic names that
were not consistent across the industry. Every time you walked into a library, you would have to learn a
whole new taxonomy just to find a book.
Other cataloging structures are more flexible. For example, a fashion boutique may keep all shirts in one
section, others may stock items by price, whereas another stores different items by color so that customers
can browse for a complete outfit in related shades. Each of these is a valid approach, and customers learn
how each store manages their information (items) architecture (storage and retrieval environment).
There is no single information architecture that works for all organizations; if there was, it would be hard
coded into all solutions. For example, it would be impossible to shop in a supermarket that stored all its
2-10 Designing an Information Architecture
itemsproduce, canned goods, bread, meat, and so onby color. However, a paint store that catalogs
primarily by color is a realistic possibility.
The importance of information architecture

Without a well-designed information architecture, you may find that your information is easy to store,
because users can save documents wherever they like, but impossibly difficult to find.
A well-designed information architecture can mean:
Increased usability and discoverability. Users, both contributors and consumers, feel comfortable with
the containers of their information; these are easy to use, relevant to their work, and meaningful.
Enhanced performance. The faster storage and retrieval of information improves performance. Do not
confuse system performancethe speed with which disks or networks react to requestswith
business performance. The International Data Corporation (IDC) reported that studies by the
Association for Information and Image Management (AIIM) and Ford Motor Company estimate that
knowledge workers spend 1525 percent of their time on nonproductive informationrelated
activities. This time is immensely larger than the time spent waiting for a system to respond.
Better user adoption. The first two factors mean that users are more likely to have faith in their
business systems and will, therefore, use them, rather than spend their time looking for workarounds
and alternatives.
Responsiveness to change. All organizations change, and a well-structured information architecture

should be able to accommodate change. The DDC is over 150 years old, but you can find SharePoint
under 000, in the Computer Science, Knowledge, and Systems Class; that is proven flexibility.
When you develop an information architecture, you need to ensure that you understand the data items
that you need to store, how these are going to be used, and the rules of governance in your organization.
You also need to ensure a level of flexibility so that you do not create an architecture that is so closely
linked to your current information that it cannot manage new information types when they arise.
Reference Links: For more information about the importance of IA, refer to the IDC
white paper, The High Cost of Not Finding Information, Feldman and Sherman (2001) at
http://go.microsoft.com/fwlink/?Linkid=299522
What Drives an Information Architecture?

There are two key facets that drive an information
architecture: the ability to store content and the
ability to retrieve content. Just about everything
else, such as security or manageability, is a feature
of one or both of these two activities. This means
that your first step in identifying your information
architecture is to identify what people want to do
with their content and how they want to do it.
In your organization, you need to identify:
The types of information you hold.
How that information gets to where it needs

to be.
How users locate and consume the information.
The volatility of the information.
Information formats
2-11
We tend to think of information in the form of documents. This is hardly surprising, because we have
spent the last few decades dealing with documents that we load in applicationsdocuments open in
Microsoft Word and spreadsheets open in Microsoft Excel. This has led to an instinctive cataloging of files
together by application type, rather than function, in folders. You must avoid this assumption. It may be
the case that you should be using folders as an integral part of your information architecture, but
remember that you can use metadata and an organizational taxonomy to help catalog items.
Undertaking Your Information Architecture Design

To start any IA design project, you must identify
five key elements:
Goals. What are you being asked to do and,

equally importantly, what are you not being
asked to do? Make sure that your goals are
the organizations goals; often IA designers
can be tempted to develop a better business
environment rather than to design an IA that
serves the one that everyone else currently
works in.
Design. Identify any design constraints. These

can include the usual resources, such as time
and access, but may also include design standards enforced by the business.
People. Identify the key stakeholders. In addition to the most senior people who sponsor the project,
this also includes the users of information in the organization. If you fail to engage with both of these
groups, you are unlikely to build a successful IA.
Context. Ensure that you understand the culture of the organization and how information flows
between contributors and consumers.
Technology. Although an IA should be technology-agnostic, you would be foolish to ignore the

boundaries of the technological environment in which your IA has to exist. You must know the IA
facilities available from the organizations business systems and, more importantly, the physical and
logical boundaries of any platform.
Information Architecture Goals
Planning and designing an IA is no different from

any other project. You will fail if you cannot write
down the goals at the outset and get these agreed
upon and signed-off by the project sponsor and
the organizations senior management. An IA is a
somewhat abstract concept, and even the project
sponsor may struggle to give you an exact brief.
Part of your job is to help in the project
specification process, especially if the specified
goal is something that cannot be measured. Often
people can articulate a problem, such as, No one
can find anything. Unfortunately, this is probably
untruepeople can always find something, it just may not be what they wantand it does not give you
any criteria for success. Help the sponsor define the problem in terms that can be more readily converted
into metrics.
For example, it may be that the sponsor and his team are concerned that users spend 20 percent of their
working day trying to find the information that they need to complete their work. That is a measurable
challenge. You need to identify what would be considered a successful resolution to this problem.
Remember that getting this down to 0 percent will be impossible, so identify a measurable target that is
achievable and acceptable to the sponsor. In this case, reducing the search time to 10 percent may be
considered a success. Make sure that you agree with the initial assessment by testing any metrics on the
current situation. Is the 20 percent in the example just a randomly selected number, or is it the result of
some business analysis? The former means that you have to test the assumption, and the latter means you
have a ready-built use-case to test your IA.
What formulates your goals?
Information architecture is about storage and retrieval, or contribution and consumption. Think about
your organization and estimate how many different types of information are created and used each day;
the number of individual items may run to tens or hundreds of thousands, but you need to focus on the
types of information that are processed. For example, most organizations generate invoices. There may be
many of these items, but it is a single information type. The sheer volume of information you have to
assess when you decide to create an information architecture can be daunting and can also lead to an
information architecture that is so complex that it becomes unusable. You must focus on the core types
and then, if necessary, identify subtypes. For the majority of organizations, there are relatively few types,
probably running to tens, rather than hundreds, with a number of related, but subordinate, variations.
Usability
There is an innate tension between storage and retrieval; between contributors and consumers. When
contributors create pieces of information, they want to put it somewhere. You need to ensure that your IA
streamlines this process. However, you also need to remember that consumers need to find the items. If
an organization creates hundreds or even thousands of information items, you need to provide an IA that
makes each item findable. Usually, the more information that you have about each itemmetadata about
the item, such as its context or purposethe easier it is to find. Of course, the more information that you
ask the contributor to include in the form of metadata, the longer it takes to store content.
When you define your storage and retrieval goals, make sure that you understand the context that drives
the information usage. If a site presents information to customersfor example, on an Internet-facing
sales siteit is essential that you make it as easy as possible for them to search for information items,
especially in the form of products. The context will drive your design and, in this example, it will provide
an easily measured resultthe number of clicks that it takes customers to find product items.
Maintainability
Maintenance is an important function of any system, so you must ensure that you establish the
maintenance criteria for your IA. Maintenance is a function of update or change, so make sure that you
understand the importance of each to your sponsor and your users.
In the Internet-facing sales site scenario, it may be essential that new products are brought online
(updated) as quickly as possible. In this case, you need to identify how long it takes a contributor to
publish a new item. Again, this is easy to measure, and you can establish the acceptable set of success
criteria. Alternatively, it may be that your sponsor needs to manage constant change, because the
organization maintains fast-changing product groups based on a wide range of suppliers. You must
ensure that your design is sufficiently flexible and agile to accommodate regular change in the IA. A
tightly-fitting IA that works well for a snapshot of time may not be appropriate for managing longer term
transition.
Extensibility
You must ensure that your IA accommodates key boundaries in the customer environment, including:
Software. You must understand the boundarieslimitations or maximum capabilitiesof your

software environment. There is no point in creating an IA solution that cannot fit into your sponsors
organization. Specifically, SharePoint has a list of supported software boundaries that you should
consider strongly in your logical design when developing your IA.
Security. Make sure that you understand the importance of security to your sponsor. This should
include a thorough assessment of regulatory and statutory rules, as well as business standards, such as
company confidentiality. Your IA should streamline governance.
Management. Ensure that your IA can be managed by the organization. All organizations have a
management structure, so you should strive to confirm that the organization is comfortable in
managing your IA and working within its structures. The key to this is training. You must ensure that
everyone in the organization understands the benefits of a well-structured IA and their role in its
maintenance.
Documentation
You must document your sponsors IA requirements. This focuses the entire IA team and ensures that you
can always check your progress against the features requested by the customer. The initial requirements
documentation should also be the basis for the ongoing IA documentation. It is essential that you
thoroughly document your IA, identifying structures for usability, security, and maintainability. This will
make it far easier to test and modify the IA in the future. Like all documentation, the IA is a living thing
and should be updated regularly.
Information Architecture Design

There are two main approaches to developing an
IA. They are:
Traditional, information-driven analysis.
Agile, iterative design.
There is no right or wrong approach; you need to

identify which best suits your project.
Traditional, information-driven analysis
The more traditional approach involves

completing the analysis of the information flow
across the organization before you initiate system
development. This has advantages in that you can be confident that your IA fits well with the organization
and it minimizes the need to change design as you proceed to application development. However, it can
be slow, especially in the case of a large or complex organization.
The traditional approach normally takes longer because the information gathered from users and business
managers is validated against the existing documentation in the organization. This enables you to verify
that what people say happens really does happen. This validation provides a more robust analysis,
because it can be both quantitative and qualitative. However, customers who have identified a problem
want to see it solved, and usually solved very quickly. You need to set expectations and agree to the
design approach. This will help ensure that your sponsor does not lose confidence because the analysis is
taking longer than anticipated.
It is important to establish project milestones for your design. These should match you goalsusability,
boundaries, and maintainabilityso that you can show progress. This approach also mitigates the
potential catastrophic failure that can be associated with a design that is not assessed and tested before it
is published. If you are wrong at the outset, you will be very wrong by the end.
This form of IA analysis can fit for any organization, but you need to be sure that the project sponsor is
aware and supportive of the design approach.
Agile design
Agile application development is a popular methodology; the approach commonly means that the
development team makes a version of a solution, tests it, and then makes additions and changes based on
the test results. This provides a fast development environment, where sponsors and users can become
involved with system development through their roles in user acceptance testing (UAT), which occurs
throughout the development process. Documentation management in an agile design and development
environment is crucial, so you must be sure to maintain and update the IA documentation in line with
development cycles.
For IA, this means that the designer works to identify the high-level IA structures for use and security and
then adds layers of information management as driven by user testing. This often leads to a more
pragmatic approach to the more traditional model, because the IA designer works with the development
team and UAT staff to design what works in practice, rather than becoming overly purist about
information structures. Whether that is a good or a bad thing is debatable, so it is even more essential
that you can return regularly to a documented user requirements specification to ensure that the design
has not deviated from the core goals.
Iterative development beyond agile design
An information architecture may look like a destination, but it is more like a journey. The reason for this is
that all organizations change. Your information architecture reflects your organization, so you must be
2-15
prepared to make regular adjustments to maintain its relevance. This is the case irrespective of whether
you select a more traditional methodology or an agile design methodology.
Information architecture changes
You need to be alert for the events that can trigger the need for change in your information architecture.
These may be obvious, such as the purchase of a new company, or more subtle, such as changes to
statutory regulation. These are seldom IT-related changes, so you must maintain links with the
stakeholders that you identified when developing the original business mapping.
You should note what may change in the core information architecture drivers:
Changes in information use
New security requirements
Amendments to regulatory requirements
Changes to working practices
Changes to organizational structure
Information architecture reviews
Although users are usually the best source of information, they typically do not suggest information
architecture changes. Instead, they will more often identify a workaround that enables them to work
effectively in the existing environment. To mitigate against informal information architectures, you must
be proactive in engaging with your users.
You have already established the development of an information architecture as being integral to the
business; now you have to hold regular change review sessions with key personnel. These should be
conducted to touch base and ensure that the current solution is still fit for its purpose, not to instigate a
new information study. The result of such meetings may be as simple as a new SharePoint 2013 site
column or content type to service a new business condition.
Information Stakeholders and Context

The context of an organizations information is
inextricably linked to the stakeholders, so an IA
designer is well advised to review both
stakeholders and information context at the same
time.
Identifying and using stakeholder

knowledge
The first step in defining a robust information

architecture is to identify the information
stakeholders. This does not simply mean that you
identify the business leaders or managers. Going
to the business managers for direction can appear
to be the solutionwho knows the business better? The business organization is the province of the
leadership team, but the items of informationfiles, documents, dataare often the domain of the
knowledge or information workers. While ensuring that you listen to the business, you must be careful to
avoid creating an information architecture that simply mirrors the organizational structure.
When you ask managers to define their information organization, they commonly reflect their
organizational hierarchy:
Company >> Division >> Department >> Team >> Project
This may also be the response of most staff, but this organizational taxonomy may not be the best way to
design your taxonomy, because it may not be the best or most efficient way to catalog your information.
For example, if a staff member needs to find an expenses claim form, where does he or she look? The
Finance division is probably responsible for expenses and the forms associated with claims, but it is more
likely that a user will access his or her own departmental folder that holds these sorts of thingsexpense
claim, sick-leave, holiday forms, and so on. Each department may store different versions of these forms,
which typically have evolved over time. This means that there may be multiple versions of what is,
essentially, the same form. Each may have subtle differences, many of which may not reflect the needs to
the Finance division, which ultimately processes all expense claims.
Rather than simply reflecting the organizational hierarchy, you could try to define an informational
structure:
Company >> Employees >> Forms >> Expenses Claim Form
This will mean that the form is consistent and universal, everyone knows where to find it, and all instances
can be changed based on the Finance divisions requested changes (for example, amending the mileage
allowance to reflect a change in taxable status). This is a simple example, but it shows that you, as an
information architect, need to think outside the organizational box.
Contextualizing information
Your information stakeholders represent all those people who touch information items. They will
understand the following contextual content information:
Information purpose. You must understand what the information is used for: is it for customers or is it
for internal staff use; is it standalone or does it only have a meaning in the context of other pieces of
information; or, can it be deleted when used, or must it be retained for regulatory reasons?
Information creation. You must know who creates the information and how they do it. This does not
simply mean the application used by the staff to create items, but also the environment in which the
users work. You must find out how much time a contributor has to create an information item; if a
contributor is in a situation that is under extreme time-pressure, your information architecture must
ensure that information storage time is minimized.
Information consumption. Investigate who uses business information and find out how they like to use
it. Perhaps most important, you need to find out how they find the information that they need to
complete their work. Remember the 2535 percent of time that is wasted by knowledge workers;
your design must emphasize discoverability.
Information value. Some information is very high-valued data. This may be due to confidentiality or to
its integral importance to the running of the business. You must ensure that your information
architecture identifies key data and ensures that it is managed appropriately.
So who do you go to to learn all of this information? Clearly, it is the business staff, executives, managers,
and knowledge workers; note that it is not you. Do not approach your design feeling that you know your
organizations information best. Your design should include input from all levels of the organization and,
where possible, you should cross-reference your findings between groups. The information that one
member of staff feels is confidential may be regarded as for public consumption by others.
Information Architecture and Technology

SharePoint 2013 is the technology platform that is
available in this course to define the physical and
logical boundaries of the IA, and provide the
facilities that make it possible to build and deploy
an effective information architecture. It is essential
that you understand the key options available on
the platform that will influence your designboth
because of the opportunities offered and the
limitations imposed.
2-17
SharePoint 2013 offers a rich and broad range of

functionality for the IA designer. The diverse
business workloads, such as Web Content
Management, Enterprise Content Management, and social computing, make it feasible to construct an IA
that spans all areas of an organization. Central to this capability is the Managed Metadata Service, which
enables you to define an organizational taxonomy that is consistent across all spheres of business life.
Specific features of SharePoint 2013 that you need to understand and incorporate into your design
activities include:
Managed Metadata Service.
Site columns.
Content types.
Term sets.
Information management policies.
These are all discussed in detail in the next lesson.
SharePoint also provisions options for driving navigation, and therefore discoverability, from the output of
your IA design. Integration of IA across content creation and consumption drives user familiarity and
adoption. For IT and business managers, SharePoint 2013 IA emphasizes the importance of information
governance by provisioning integrated information management policies that you can implement as part
of your IA.
Discussion: What Is Your Experience of Information Architectures?

IA design is a broad topic. What is your experience
of IA in your organization?
Lesson 3
Organizing Information in SharePoint 2013

SharePoint 2013 has a range of facilities and components that help organize information in an
organization. An IA designer must understand the options available and how these can be used to
encourage user adoption of information structures.
In this lesson, you will learn about the integral functionality, such as Managed Metadata, content types,
and term sets that will enable you to create and disseminate an IA.
Lesson Objectives
Describe the SharePoint 2013 container hierarchy.
Describe the functions of the Managed Metadata Service.
Explain the function and use of site columns and content types.
Describe term sets.
Describe the function and options for information management policies.
The SharePoint Information Architecture Container Hierarchy

When planning your information architecture, it is
important to understand the SharePoint 2013
container hierarchy. The term container refers to
the logical structures that make up SharePoint
2013. The container hierarchy is as follows:
Farm
Web applications
Site collections
Sites
List and libraries
Items
Farms
The farm, as the top-level container, is not usually part of the information architecture design. However,
the farm defines the top-level resources that may affect the information architecture, such as the
availability of service applications. The Managed Metadata Service will be integral to any IA design.
Web application
A SharePoint web application typically has a one-to-one mapping with an Internet Information Services
(IIS) website. Your design must consider how many web applications will be needed for your information
architecture. The more web applications that you have, the more URLs you will need, and the greater the
management overhead. You should also note that additional URLs can also mean more SSL certificates
and increased expense and management.
Site collection
2-19
Site collections are the first major design tier in the hierarchy when designing an information architecture.
Site collections are:
A logical boundary for security.
The point at which quotas are set.
A functional boundary for some design elements:

o
Most out-of-the-box Web Parts do not cross site collection boundaries.
Navigation does not always work across site collections, because SharePoint groups are defined
within a site collection and do not work across boundaries.
You must consider the following trade-off. You can use Search to be the query-engine across site
collections to manage the Web Part limitation. However, this does have a latency issueit is only as
current as the last crawl.
Site
A site is a logical unit of containment that contains lists, libraries, and configuration settings. Each site can
have customized security and navigation, but more commonly, an IA uses inheritance from the site
collection tier to minimize administrative overhead.
List and library
A list (or library) is a logical container that holds a collection of similar items such as contacts,
appointments, documents, and pages. Each list or library contains columns of various data types (for
example, text and date). Lists also contain configuration settings, permission levels, and views. You can
also create folders in libraries to create security boundaries, though this is not recommended for
information organization.
The Managed Metadata Service Application

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. These can be
published across site collection boundaries.
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, which is in itself a site collection.
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. 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.
Planning Site Columns and Content Types

In SharePoint 2013, 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.
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. A SharePoint 2013 library is a specialized
form of a SharePoint 2013 list that stores document-type 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. When you plan custom columns, avoid using the same column
name twice to clearly establish metadata and column associations.
Content types
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 includes 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.
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.
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 librarytype 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 helps ensure 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 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.
Content type publishing in SharePoint 2013
In SharePoint 2013, content types that you create in one site collection are restricted to use within that
site collection. By 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.
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 the content type. However, unpublishing will not remove the content type from a
subscriber site if that content type is already in use.
Note: Content type hubs and content type publishing are covered in greater detail in
Module 11.
Planning Term Sets

SharePoint 2013 term sets provide the ability to
tag information to improve usage clarity by means
of a managed list of terms. Term sets are
provisioned and maintained by a central function
and by unmanaged lists, which provide flexibility
for users to add personal comments. The term sets
add metadata information that is surfaced as part
of a documents properties, by using the managed
metadata column.
Term set terminology

SharePoint 2013 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 the office
locations for a company, 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 set owner. Term sets have a user known as a term set owner. A term set owner does not have
any specific permission on a term set, but the user is listed as a contact for query or reference
purposes.
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.
Term group manager. A term group manager can 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.
Deprecating a term takes that term out of service, but it does not remove it from any items where that
term is already applied. SharePoint 2013 stores terms, term sets, and term groups in the term store. There
is one term store for each instance of the Managed Metadata Service.
Term set functions
Term sets are designed to help the information consumer by provisioning either additional information,
which can help to source a document, or to suggest alternatives through the use of synonyms. The core
functionality provided by term sets includes:
Auto-suggest. As the user types characters into the Managed Metadata field, type-ahead functionality
offers a list of possible options based on the term set taxonomy.
Hover tooltip. Pre-defined term attributes display when the users mouse pointer hovers over an item.
Preferred terms. This provides the default naming for a term. This helps to minimize the number of
multiple terms that define the same items, such as Corp, Corp., or Corporation.
Description. Contextual guidance on term usage for contributors.
Synonyms. Like preferred terms, this provides a list of synonyms for terms to encourage storage
consistency.
2-23
Users can provide feedback on terms through the Send Feedback option. This sends responses to the
Term Group Manager. This can be a useful tool, as part of your iterative IA development.
Folksonomic term set functions
Unmanaged term sets enable users to add more personal comments as metadata. The terms can include:
Tags. Tags are used to organize and bookmark items. A user can tag:
o
Internal web pages.
External web pages.
List items.
Documents.
Notes. Notes are short annotations that a user can add any item with a URL (internal or external).
Ratings. Users can add their evaluation on webpages, lists, and documents by using a scale from one
to five.
Planning Information Management Policies

Information management policies enable you to
specify settings for document or item behavior.
The information management policies must
adhere to the governance implemented for your
organization. Governance specifies the protocols
and standards of an organization, such as the
security status of a documentPublic, Company
Confidential, and so onor how users must
manage the life cycle of a piece of content. The
following table describes the SharePoint 2013
information management policy 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 stages to the retention settings
so that you can configure more complex management
policies.
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.
Labels
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.
This feature has been deprecated in SharePoint 2013.
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. For example, when you apply policies to a
content type, you can 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.
Navigation as a Feature of Information Architecture

One of the core functions of metadata is to
improve the discoverability of information.
Although most users focus on the navigation
hierarchy to browse for information, it is important
that you assess the suitability of SharePoint 2013
metadata navigation for your IA. Metadata
navigation presents users with navigation options
that are based on tags applied by contributors to
their content. This delivers results that are filtered,
or refined, by the taxonomy delivered by managed
metadata columns.
There are three navigational options:
Navigation hierarchies. These present a tree-based (expandable and collapsible) hierarchy that reflect
the values of a selected field. A user can expand a term set and select terms to filter the current view.
The filter displays the documents with that term. If a selected term has associated children, they are
included in the filter.
Filters are also available for document libraries. A user can browse managed metadata fields with
selected terms applied as filters.
Key filters. Key filters enable users to filter a document library view based on taxonomic values bound
to a field. Unlike navigational hierarchies, with key filters, a user enters keywords into a text field, and
terms are returned through auto-suggest functionality. As an extension to this functionality, a user
can click the tags icon to display a list of selectable terms.
Product catalogs. With an online product catalog, you can configure a term set defined in the site
collection where the product catalog is created and specify its intended use, by selecting Use this
Term Set for Faceted Navigation, during configuration. You can then add a refiner Web Part to a
category page and configure the Use the refinement configuration defined in the Managed
Navigation term set option.
Note: The product catalog and its use in navigation is covered in detail in 20332A:
Advanced Solutions of Microsoft SharePoint Server 2013 Module 9: Planning and Configuring
Enterprise Content Management.
The use of term set navigational functions facilitates the adoption of an IA, because the navigation evolves
organically with changes and updates to the architecture. The consistent use of terms and their
integration in user solutions or applications emphasizes the effectiveness of the IA design.
Lab A: Creating an Information Architecture Part One

Scenario
The IT team at Contoso has finished gathering the business requirements for the new SharePoint 2013
deployment, and the key stakeholders have approved its findings. Your task is to create an information
architecture design that incorporates these business requirements.
The information that your team has gathered is detailed in the supplied documents. Use these documents
to design a site structure, including potential site columns and content types.
Your whole class will work together to discuss the requirements and complete the Content Types sheet in
the Information Architecture Planning worksheet. Your instructor will facilitate your discussions.
Objectives
In this lab, you will be able to:
Identify potential site columns and content types from business requirements.
Estimated Time: 60 minutes
Virtual machines: 20331B-NYC-CL

o
User name: admin
Password: Pa$$w0rd
Exercise 1: Identifying Site Columns and Content Types

Scenario
As part of your analysis, you have completed interviews with a range of stakeholders and users. Based on
the transcripts of these, you must identify the information architecture elements for site columns and
content types.
The main tasks for this exercise are as follows:
1. Read the supporting information
2. Complete the Content Types sheet in the Information Architecture Planning worksheet
Task 1: Read the supporting information
Start the 20331B-NYC-CL virtual machine.
Log on to the 20331B-NYC-CL machine as admin with the password Pa$$w0rd.
Read the lab scenario.
In the E:\Mod02\Starter folder, read the business requirements and interview transcripts in
Information Architecture 1 - Contoso Requirements.docx file.
Task 2: Complete the Content Types sheet in the Information Architecture Planning
worksheet
In the E:\Mod02\Starter folder, complete the Content Types worksheet in the Information
Architecture Planning worksheet.xlsx file, replacing the ?? with valid options, based on the
business requirements.
Note: In the Site Columns list, you should identify requirements from the requirements
documentation.
In the Content Type column, you should use the drop-down list to select an appropriate option,
based on the requirements documentation.
In the Comment column, you should add any options or calculations that should be used to
populate the content types you have selected, based on the requirements documentation.
Do not complete the Taxonomy sheet, because you will do this in a later exercise.
Results: Design of the site columns, content types, and term sets necessary to satisfy the business
requirements.
Lesson 4
Planning for Discoverability
The term discoverability covers a range of technology areas in SharePoint 2013. You have already seen
that making information readily available to users is one of the pillars of IA design, and discoverability is
one fact of that availability. An IA designer must consider information availability through Enterprise
Content Management (ECM), Search, and Navigation to create a holistic solution. Central to ECM and
Search are taxonomies. These are closely related to information architecture, but they are commonly more
tightly structured.
In this lesson, you will see how each of these elements can be affected by the functionality offered in
SharePoint 2013.
Lesson Objectives
Describe how to design an organizational taxonomy.
Explain the function of keywords and how to use them.
Describe the use of query rules.
Explain how metadata and term sets can be used to develop navigation structures.
Describe the function of managed properties.
Designing a Taxonomy
Taxonomy is the logical organization of content in
an Enterprise Content Management (ECM) system.
ECM provides standards and services to manage
business content, such as records, so that it is
readily available to users. The management of
enterprise content relates to information
architecture because it is often the content that is
crucial to a users everyday work activities. Too
often, ECM is treated as a SharePoint function that
is separate from a users more casual interaction
with information on webpages. Although this is
not strictly the same as information architecture,
which includes the logical and physical storage and retrieval of content, it is probable that taxonomy
design will often fall within the scope of the IA designer.
Taxonomies, like the Dewey Decimal System, are rigorously strict, predefined, staticat least they are not
changed by usersand are often a compulsory feature of information ingestion processes. There is no set
taxonomy for ECM, but you may find that taxonomies within business organizations are developed based
on region or function to reflect the geography or services/products relevant to an organization.
A taxonomic classification must provide a strict and unequivocal structure for information cataloging. This
hierarchy can become very complex, with classes, sub-classes, sub-sub-classes, and so on. Like any
rationalization or normalization exercise, you must be wary of the law of diminishing returns when you
classify to such an extent that each class is so narrowly defined that it is a container for only one item. The
following are some rules you should follow regarding taxonomy design:
Add flexibility with synonyms, but do not allow user-generated terminology.
2-29
Ensure user input and buy-in to the taxonomy classification.
Do not include catchall options, such as Other; people will start to use them by default and the
usefulness of the taxonomy is reduced.
You seldom need to classify beyond four levels.
You can import taxonomies in comma-separated value (CSV) files.
Use a familiar term for your taxonomy. Users may feel more comfortable with the word classification
rather than taxonomy.
Taxonomy columns should be mandatory.
Do not allow use of the Windows Explorer view; this can enable users to bypass your taxonomy,
unless you use folders for location-based metadata defaults.
You can have multiple taxonomies across an organization, which may necessitate:
o
Multiple Managed Metadata Services (MMS) columns.
Each taxonomy being a term store in MMS.
Discussion: Identifying a Taxonomy for Litware Inc.

A good example of a familiar taxonomy is book
genres. Review the taxonomy on the slide for
books at a company called Litware Inc. and
consider any additions or amendments that you
would make. During the class discussion, fill in the
missing options (marked ??) and make up some
more of your own. The goal is to establish the
structure and encourage analysis of relationships
between terms.
Designing Keywords
SharePoint 2013, together with SharePoint Online,
provides the facility to collect enterprise keywords
into a single, non-hierarchical term set, named the
Keyword Set. This can be managed by using the
Term Store Management Tool.
The keywords that users add are available to
others when they use the list or library. When a
user adds an enterprise keywords column to a list
or library, SharePoint 2013 copies any existing
document tags into the enterprise keywords
column when users upload new documents to the
list or library. This feature helps to maintain
synchronization of keywords with managed metadata features.
The keyword set can be configured as:
Open. Users can add new keyword values.
Closed. Users cannot submit new keyword values; they can only use existing managed terms.
The keyword set can be configured as Open or Closed by a term store administrator. You can use this
approach to establish a stable keyword list that you can then move into a managed term set.
Adding an enterprise keywords column to a list or library
Users can add enterprise keywords to items on a SharePoint 2013 site, so that they can use the keywords
for tagging and to develop a folksonomy. Enterprise keywords are a good way to capture some of the
knowledge of the people who use the content. To make it easy for users to add keywords, you can add a
special enterprise keywords column to a list or library. Then, to add a keyword to an item, users just select
the item and enter the word or phrase they want in the item properties.
Users can add keywords in the document properties dialog box.
Users can use the following steps to add an enterprise keywords column to a list or library:
1.
On the ribbon for the library or list, click Library Settings or List Settings.
2.
In the Permissions and Management column, click Enterprise Metadata and Keyword Settings.
3.
On the settings page, in the Add Enterprise Keywords section, select the Add an Enterprise Keywords
column to this list and enable Keyword Synchronization check box.
Query Rules
Query rules are a new feature in SharePoint Server
2013 that enable the query engine to act on what
it interprets or infers about the query intent. Query
rules have replaced search keywords, which have
been deprecated. The difference between the two
is that query rules return results that may be
relevant to the user query, whereas search
keywords promote only one specific result set.
Query rules, which execute at the site collection
level, can enable a single user search request to
trigger multiple queries and, therefore, multiple
results sets. In SharePoint 2013, query rules have
replaced the use of Best Bets.
Query rules are a function of a site collection Search configuration, which is found on the Site Settings
page. A Query rule is made up of three components:
Query condition. This defines the context in which the query becomes active, such as when a query:
o
Contains a specific word or words.
Contains a word that is specific to a dictionary.
Contains an action word that matches a specific phrase or term set.
Is common in a different source.
Results include a common result type.
Note: Each query can have multiple conditions, which can increase the scope of potentially
pertinent search results.
Query action. This defines the action that should occur when a condition is met. These actions include:
Assigning a promoted result (similar to a Best Bet in SharePoint Server 2010).
Creating and displaying a result block.
Changing the query that returns the core results.
2-31
Publishing option. This decides when a query is used. This is particularly useful in commerce sites,
because the publishing options can set a time period on when a rule is available, such as special offer
events or sales.
There are several query rules available out-of-the-box with SharePoint 2013. In an environment that is
upgrading from SharePoint Server 2010, SharePoint Server 2013 automatically migrates all search
keywords to query rules.
Managed Properties
Crawled properties are metadatafor example,

Author or Titleextracted from documents when
the document is crawled. A crawled property, such
as Author, may be held in different content
sources but use a different term to describe the
same thing. For example, one source may use
Writer whereas another user may use Contributor.
Author, Writer, and Contributor all mean the same
thing, you can create a single managed property
to which all the other crawled properties are
mapped. That means that you have a managed
propertyAuthorand you map other crawled
propertiesAuthor, Writer, and Contributorto that one managed property. Your managed properties
can appear in refined searches and help users perform more successful queries. Refined searches can be
performed only on managed properties, not crawled properties.
In SharePoint 2013, an administrator can create managed properties down to the site collection level. This
enables the designer to define custom attributes associated with business data for purposes of filtering,
reporting, and refining. Managed properties can still be created at the Search service application level.
In SharePoint 2010, it was necessary to run a full crawl of all content to create a crawled property, and an
additional crawl to create a managed property. This has been changed in SharePoint 2013. Now, when an
administrator creates a site column, it is automatically configured to be a managed property before the
crawl.
To create a new managed property, you can go into the Site Settings and then Search Schema in the Site
Collection Administration section. From this page, you can create a new managed property and map it
back to the crawled property.
There are three limitations on managed properties at the site collection level:
They can only be text.
They cannot be sortable.
They cannot be refinable.
To provide this functionality to site collection managed properties, SharePoint 2013 ships with managed
properties that can be used to provide non-text, sort, and refine options. For example, on the list of
managed metadata properties these appear as:
RefinableDate00.
RefinableDate01.
RefinableDate02.
RefinableDecimal.
RefinableDouble.
RefinableString.
Lab B: Creating an Information Architecture Part Two

Scenario
After completing your information architecture design for manageability, you must now extend the
information architecture to include discoverability.
Your whole class will work together to discuss the requirements and complete the Taxonomy sheet in the
Information Architecture Planning worksheet. Your instructor will facilitate your discussions.
Objectives
Produce a taxonomic information architecture design.
Estimated Time: 30 mins

o
User name: admin
Password: Pa$$w0rd
Exercise 1: Designing a Business Taxonomy

Scenario
As part of your analysis, you have completed interviews with a range of stakeholders and users. Based on
the transcripts of these, you must identify the information architecture elements for a consistent business
taxonomy.
2. Identify the business taxonomy from the requirements document and interview transcripts.
In the E:\Mod02\Starter folder, read the information and interview transcripts in the Information
Architecture 2 - Contoso Requirements.docx file.
Task 2: Identify the business taxonomy from the requirements document and
interview transcripts.
In the E:\Mod02\Starter folder, open the Information Architecture Planning worksheet.xlsx file
and complete the table in the Taxonomy worksheet.
Results: The design for a business taxonomy.

In this module, you learned about the elements of an information architecture and how to plan these
architectural elements for a SharePoint 2013 environment.
Review Question(s)
Test Your Knowledge
Question
When you undertake an information architecture design project, which of the following
elements define the culture of the organization and how information flows between
contributors and consumers?
Context
Design
Goals
People
Technology
Test Your Knowledge
Question
Which of the following names describes a list of related terms?
Term
Term set
Term group
Term group manager
Contribution
Statement
An organizational taxonomy is most
widely used in Enterprise Content
Management.
Answer

3-1
Module 3
Designing a Logical Architecture
Contents:
Module Overview
3-1
Lesson 1: Overview of SharePoint 2013 Logical Architecture
3-2
Lesson 2: Documenting Your Logical Architecture
3-6
3-13
3-15
Module Overview
This module reviews the logical constructs of Microsoft SharePoint Server 2013 and SharePoint Online. It
discusses the importance of creating 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 Microsoft SharePoint Server 2013 that you must map to business specifications.
Objectives
Map business requirements to SharePoint 2013 architecture components.
Explain the importance of documentation and describe the options for documenting logical
architecture.
Lesson 1
Overview of SharePoint 2013 Logical Architecture
3-2
The logical architecture of your business is the basis for your design. After you gather the business
requirements, you must map these against the SharePoint 2013 logical architecture. This module provides
an overview of the key logical architecture components. Using this information, you can make key
decisions about how SharePoint 2013 can service your business requirements.
Lesson Objectives
Define logical architecture.
List the SharePoint 2013 logical architecture components.
Describe multi-tenancy functionality that may affect logical architecture design.
What Is a Logical Architecture?

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 on your design. This means
that you must provide information in a nontechnical format that clearly documents business
requirements.
You logical architecture will always be influenced by the structures, such as the container hierarchy, and
the software boundaries of SharePoint 2013, so you must have a good understanding of the SharePoint
software and security boundaries.
Reference Links: For detailed information on software boundaries, see Software boundaries
and limits for SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299523
SharePoint 2013 Logical Architecture Components

The SharePoint 2013 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.
3-3
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.
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, 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 2013 products, you can either select a preexisting 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 website that SharePoint 2013 creates and uses. You can extend a web
application up to four times to create additional zones in SharePoint 2013, which results in up to five IIS
websites that are associated with a single web application. Each IIS website is associated with a different
zone and you can assign a unique domain name to each.
Zones
3-4
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 multiple IIS configurations
for the same web application.
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 top-level website 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. SharePoint
2013 focuses site collection publishing on host-named site collections, rather than Alternate Access
Mappings (AAM) to make site collections available via multiple URLs. Although AAM is still an option, we
recommend that you design your logical architecture for publishing site collections with unique DNS
names.
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 webpages, 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 columns of various data types (for example,
text and date). Lists also contain configuration settings, permission levels, and views.
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.
Hosting and Multi-Tenancy

You can define hosting and multi-tenancy as
follows:
Hosting. The provision of distinct SharePoint

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).
3-5
Multi-tenancy is primarily designed for hosting

companies, who supply SharePoint services to
external, or tenant, customers. Administrators can
deploy and manage features and services in Partition Mode, which maintains unique and separate user
data environments, 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:
Hardware and IT costs. Each environment, which is sometimes referred to as a property, requires
unique configuration; therefore, each environment requires unique hardware and management
resources.
Self-management. Users can manage their own environments, rather than a central department
provisioning 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.
Lesson 2
Documenting Your Logical Architecture
3-6
A logical architecture is not as visible in the same way that physical architecture components can be seen
and audited. This makes it critical to have robust documentation, such that you could rebuild the
environment from scratch if necessary. Do not confuse robust and lengthy. 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 concise and 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.
Lesson Objectives
Define the contributors to, and components of, good documentation.
Describe the process of mapping business requirements to logical architecture.
Describe the Logical Architecture Planning Worksheet.
Describe how to categorize business requirements.
Transpose categorized business requirements to the Logical Architecture Planning Worksheet.
Describe why you should use diagrammatic documentation.
Introduction to Documentation
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 to be
approved by stakeholders, and a change control trigger. Of course, the documentation is also the
blueprint for development, deployment, and maintenance.
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 on 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.
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.
What should you document?
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 2013 technologies. If the logical design is incorrect, the
implementation will not service the business requirements.
Your documentation must include the following elements:
Information architecture
Logical architecture design
Service application architecture design
Physical design
Security and authentication design
Metadata design
Application design:
o
Search
Business intelligence (BI)
Content management
Operations and maintenance
Business continuity
Mapping Business Requirements to Logical Architecture Requirements

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 on. 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 2013 deployment.
3-8
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.
Mapping Information Architecture to Logical Architecture

Your information architecture (IA) describes the
means you want to use to catalog and store
information in an environmentin this case, a
SharePoint 2013 deployment. A good IA is
platform-neutral, but if your IA has been
developed for your SharePoint implementation, it
will reflect the boundariesphysical, software, and
securitywithin which you must design a
deployment.
Your IA will deliver documentation of the business
requirements in the form of some or all of the
following:
Site columns
Content types
Term sets
Information management policies
Navigation options
Organizational taxonomy
Query rules
3-9
These do not, of themselves, have an important influence on your logical architecture, but what they
represent does. For example, the site columns, content types, and term sets that are identified for you
organization reflect its business boundaries. There may be terms that are used across the entire
organization, whereas others are specific to a division, or even a department. This sort of information will
have an effect on the number of Managed Metadata Service (MMS) instances that you need to implement
and how these may be shared between groups or published across farms.
Your logical architecture must be just thata logical reproduction of the organizations business
architecture. Its purpose is to make the SharePoint environment a logicaland therefore easier
environment in which your users can work effectively. Elements such as navigational term set
requirements and query rules describe how users see their working environment and will help you
understand the logic of the business components.
The organizational taxonomy will categorize and describe the information that drives enterprise content
management and search functionality for the organization. You may have specific taxonomic elements
that are specific to one division, and which should be maintained and published separately. This will have
an influence on the number of containers that you need to implement at web application and site
collection levels.
Information management policies will almost certainly affect the configuration of site collections, because
much of the information management reflects the security requirements of the organization.
Using a Planning Worksheet

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 identify 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 are 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.
3-10 Designing a Logical Architecture
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.
Sample Scenario: Identifying Business Requirements and Mapping Them to

a Logical Architecture
The graphic displays a well-structured
requirements document that contains a lot of
information regarding Litwares 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

sample business requirements document that
there is a lot of information that can 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.
FIGURE 3.1:SAMPLE OF LITWARE INC. BUSINESS REQUIREMENTS

DOCUMENT
Sample Scenario: Mapping Business Requirements

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.
3-11
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.
2.
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 will require other components to be published, such as About Us information.
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.
4.
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 websites.
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 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.
Note: When migrating to Office 365, you must go back to a single web application for
both Intranet and My Sites.
Diagrammatic Documentation
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 support staff to visualize, and contains all the information that you require to
influence detailed design for physical or other planning.

Scenario
As part of the planning and design phase for the new SharePoint 2013 deployment at Contoso, your next
task is to produce a logical architecture design. You should use the supplied business requirements and
the Logical Architecture Planning Worksheet to help you produce your logical design.
Your whole class will work together to discuss the requirements and complete the SharePoint 2013
Logical Architecture Planning worksheet. Your instructor will facilitate your discussions.
Objectives
After completing this lab, you will be able to:
1.
Use worksheets to plan and design a logical architecture.
2.
Use diagrams to document a logical architecture design.
Lab Setup
Virtual Machine: 20331B-NYC-CL

o
User name: admin
Passw0rd: Pa$$w0rd
In this lab, you will develop a logical architecture design for Contoso and create an architecture diagram
as part of your documentation.
In the first exercise, you will complete the Logical Architecture Planning Worksheet, based on the business
requirements information that is supplied to you.
In the second exercise, you will transpose the planning worksheet documentation into a Visio diagram.
Exercise 1: Plan a Logical Architecture

Scenario
You have collected information from a valid cross-section of stakeholders and users. You are now ready to
take this unstructured information and formalized it on an Excel Logical Architecture worksheet. This
transposition will take inputs from the following documents:
A business requirements document
The logical architecture requirements document

2. Complete the logical architecture planning worksheet
In the E:\Mod03\Starter folder, read the specification information in the SharePoint 2013 Logical
Architecture Requirements.docx file.
Task 2: Complete the logical architecture planning worksheet
In the E:\Mod03\Starter folder, open and complete the worksheet in the SharePoint 2013 Logical
Architecture Planning Worksheet.xlsx file.
Results: This exercise will produce a completed Logical Architecture Planning Worksheet.
Exercise 2: Produce a Logical Architecture Diagram

Scenario
You have completed the tabular documentation of the logical architecture, so you are now assigned to
produce a more visual version, in Microsoft Visio.
1. Complete the logical architecture diagram
Task 1: Complete the logical architecture diagram
In the E:\Mod03\Starter folder, open and complete the diagram in the SharePoint 2013 Logical
Architecture Diagram.vsd.
Results: This exercise will produce a diagrammatic version of the logical architecture documentation.
In this module, you learned about the elements of a logical architecture and how to plan and document
these for a SharePoint 2013 environment.
Having completed this module, you should now be able to:
Identify business requirements and describe how business requirements affect the logical architecture
of a SharePoint 2013 deployment.
Map business requirements to SharePoint 2013 architecture components.
Explain the importance of documentation and describe the options for documenting logical
architecture.
Review Question(s)
Test Your Knowledge
Question
Which of the following is a functional requirement of a logical architecture?
Compliance with capacity standards.
Adherence to performance goals.

Integral ability to service business continuity service level agreements.
Conformance with regulatory or statutory audit rules.
Assurance of scalability against future growth.
Statement
A logical architecture documents the
nonphysical structure of a solution,
designed to fulfill business requirements.
True or False?
Answer

4-1
Module 4
Designing a Physical Architecture
Contents:
Module Overview
4-1
Lesson 1: Designing Physical Components for SharePoint Deployments
4-2
Lesson 2: Designing Supporting Components for SharePoint Deployments
4-11
Lesson 3: SharePoint Farm Topologies
4-15
Lesson 4: Mapping a Logical Architecture Design to a Physical Architecture

Design
4-21
4-25
4-27
Module Overview
When you design a Microsoft SharePoint Server 2013 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 2013 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 2013 environment, so it is essential that your physical design
fully meets the operational requirements.
Objectives
Describe the physical design requirements for SharePoint 2013.
Describe the supporting requirements for a successful SharePoint 2013 physical design.
Identify SharePoint farm topologies.
Map a logical architecture design to a physical architecture design.
Lesson 1
Designing Physical Components for SharePoint

Deployments
4-2
Before committing to specific numbers of servers, you must understand the organizations 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.
Lesson Objectives
After completing the lesson, you will be able to:
Identify minimum hardware requirements.
Identify software requirements.
Identify server virtualization options.
Identify storage choices.
Identify database configuration options.
Map functional and nonfunctional requirements to your design.
Hardware Requirements
The following table displays the hardware
requirements for Web Front End (WFE) servers and
application servers that are part of a multi-server
farm.
Component
Minimum requirement
Processor (CPU)
64-bit, 4 cores
Memory (RAM)
12 GB
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.
Component
Minimum requirement
Processor (CPU)
64-bit, 4 cores for small deployments

64-bit, 8 cores for large deployments
Memory (RAM)
8 GB for small deployments

16 GB for large deployments
Hard disk
80 GB for the system drive.

Additional disk space based on database requirements.
For a development or evaluation environment, you may use a single server with a built-in database or
single server that uses SQL Server database. This should have a minimum of 8 GB of RAM and a 64-bit
processor with 4 cores. Dependent on the development activity, you may need to deploy a range of
services, but you should deploy the following:
App Management service application
Central Administration website
Claims to Windows Token service (C2WTS)
Distributed cache service
Microsoft SharePoint Foundation 2013 Site and Subscription Settings service
Secure Store Service
User Profile service application (SharePoint Server 2013 only)
Note: The minimum requirement values for a SharePoint database server are larger than
those recommended as the minimum values for the Microsoft SQL Server product itself because
of the distribution of data that is required for a SharePoint 2013 environment.
Additional Reading: For more information about hardware and software requirements for
SharePoint, see Hardware and software requirements for SharePoint 2013 at
Software Requirements
Database servers in a SharePoint 2013 farm have
the following minimum software requirements:
The 64-bit edition of Microsoft SQL Server

2012 or the 64-bit edition of SQL Server 2008
R2 Service Pack 1
The 64-bit edition of Windows Server 2008 R2

Service Pack 1 (SP1) Standard, Enterprise, or
Datacenter or the 64-bit edition of Windows
Server 2012 Standard or Datacenter
Microsoft .NET Framework version 4.5
4-3
WFE and application servers in a SharePoint 2013 farm have the following minimum software
requirements:
4-4
The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or
Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter
The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for front-end
web servers and application servers in a farm:
o
Web Server (IIS) role
Application Server role
Microsoft .NET Framework version 4.5
SQL Server 2008 R2 SP1 Native Client
Microsoft Windows Communication Foundation (WCF) Data Services 5.0
Microsoft Information Protection and Control Client (MSIPC)
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
Windows Management Framework 3.0, which includes Windows PowerShell 3.0
Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF
1.1)
Windows Server AppFabric
Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)
Additional Reading: Certain versions of Windows may need specific hotfixes to support an
installation of SharePoint. For more information about hardware and software requirements for
SharePoint, see Hardware and software requirements for SharePoint 2013 at
Some business intelligence (BI) features have specific additional requirements. The following features
require the installation and configuration of SQL Server 2012 SP1 or later for the corresponding
databases:
New Excel 2013 features, such as advanced data models or Power View sheets
Reporting Services integration, such as starting Report Builder from SharePoint or viewing Reporting
Services reports in SharePoint
PerformancePoint Services requires ADOMD.net v11, which is part of SQL Server 2012 SP1
Additional Reading: For more information about business intelligence feature

requirements, see Software requirements for business intelligence (SharePoint Server 2013) at
Virtualization Considerations
Server virtualization with Hyper-V on Windows
Server 2008 R2 and Windows Server 2012 is
commonplace in many organizations. Companies
use virtualization to improve server utilization and
management, add flexibility to data centers, and
decrease the costs that are associated with
running multiple physical servers.
If you take the correct planning and sizing steps
prior to deployment, you can virtualize some or all
of the servers in a SharePoint farm successfully.
WFE and application servers
4-5
Both WFE and application servers are both potential 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 what the same number of physical servers
would achieve. This requirement results from the performance overhead of the virtualization platform.
Using Windows Server 2008 R2 or Windows Server 2012 Hyper-V, you can achieve near parity to physical
performance with the correct planning.
Database servers
Virtualizing database servers running SQL Server can be a difficult design decision, because the
performance overhead of the virtualization platform can affect the entire solution. However, SharePoint
2013 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. You should also pay particular attention to disk performance,
because this may be shared with other virtual machines on the host.
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 configuring a virtual environment to
support SharePoint 2013, see Use best practice configurations for the SharePoint 2013 virtual
machines and Hyper-V environment at http://go.microsoft.com/fwlink/?Linkid=299527
For more information about planning a virtualized deployment of SharePoint 2013, see Plan for
on-premises or hosted virtualization in SharePoint 2013 at
Storage Options
When you plan for content storage on SharePoint
2013, 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 2013:
Direct attached storage (DAS). Hard disks are

attached directly to the computer running
SQL Server.
Storage area network (SAN). 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 and should be used with caution.
Note: Content databases with remote BLOB storage are the only configuration in which
SharePoint 2013 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.
4-6
Typically, DAS is 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 2013 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
Description
RAID 0
Offers improved performance by striping data across disks in the

array. Not fault tolerant.
RAID 1
Duplicates (mirrors) data onto a second disk in the array. Fault

tolerant, but no significant performance improvement.
RAID 5
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
RAID configuration
Description
than normal, due to the fault-tolerance requirement.
RAID 10
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.
Disk types
Different storage architectures use a range of disk types, including:
Serial Advanced Technology Attachment (SATA).
Small Computer System Interface (SCSI).
Serial Attached SCSI (SAS).
Solid State Drive (SSD) or Flash Disk.
4-7
These disk types have varying performance, capacity, and cost characteristics that you must consider when
you design your SQL Server storage architecture.
Note: For more information about how to design storage architecture based on capacity
and I/O requirements, see Storage and SQL Server capacity planning and configuration
(SharePoint Server 2010) at http://go.microsoft/com/fwlink/?Linkid=299530
Database Configuration Options

SharePoint content databases, service application
databases, 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 a best practice to store the database and log files on separate disks.
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
Default database recovery model
Farm configuration database
Full
Central administration content database
Full
Content databases
Full
App Management database
Full
Usage and health data collection database
Simple
Business Data Connectivity database
Full
Secure Store database
Full
State database
Full
Subscription Settings service database
Full
Search service application administration database
Simple
Search service application crawl database
Simple
Search service application Link database
Simple
Analytics Reporting database
Simple
User Profile service application profile database
Simple
User Profile service application synchronization

database
Simple
User Profile service application social tagging

database
Simple
Managed Metadata Service application database
Full
Managed Metadata Service taxonomy database
Full
Word Automation Services database
Full
SharePoint Translation Services service application

database
Full
PerformancePoint service application database
Full
PowerPivot application database
Full
4-8
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 2013 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 Recovery Models (SQL Server)
at http://go.microsoft.com/fwlink/?LinkID=200872
For more information about how to choose the recovery model for a database, see Choosing the
Recovery Model for a Database at http://go.microsoft.com/fwlink/?LinkID=201235 .
For more information about default configurations and growth of SharePoint 2013 databases, see
Database types and descriptions (SharePoint 2013) at
Discussion: Selecting the Recovery Model

What recovery model will you use for the farm
configuration database and the Central
Administration content database in production
deployments?
Functional and Nonfunctional

Design Mapping
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 considers
these functional requirements because they
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.
This table shows examples of functional design mappings.
Requirement
Feature
Design impact
Team collaboration
Collaboration sites
Number of WFE servers
Data analysis
Excel Services and

PowerPivot
Number of application servers
Company forms
InfoPath Forms
Number of WFE and application servers
4-9
4-10 Designing a Physical Architecture
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. 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.
Requirement
Design impact
Security
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
Discussion: Non-functional Requirements

Can you provide any additional examples of
nonfunctional requirements?
Lesson 2
Designing Supporting Components for SharePoint

Deployments
4-11
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 Active Directory directory service because the service behavior and requirements may
affect your farm topology or server placement within the network.
Lesson Objectives
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.
Requirements for Active Directory and DNS

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 Internet name resolution, for example, if you want to display Internet-based feeds on SharePoint
webpages.
Note: SharePoint 2013 does not support the use of single label Active Directory Domain
Services (AD DS) domain names. For example, an AD DS domain fully qualified domain name
(FQDN) of litwareinc is not supported, but an AD DS domain FQDN of litwareinc.com is
supported.
Design Considerations for IIS

SharePoint 2013 uses the IIS component of
Windows Server 2008 R2 or Windows Server 2012
to receive and respond to web browser requests.
You perform most SharePoint 2013 configuration
tasks in SharePoint Central Administration, but you
should be aware that you may have to perform
some web service management tasks outside
SharePoint 2013.
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 website 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.
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.
Design Requirements for SQL Server

Most small and medium-size SharePoint farm
deployments use a single database server as a
starting point. Administrators consider scaling out
to larger farm topologies only as transaction levels
increase.
There are several reasons to consider multiple
database servers to support a SharePoint 2013
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.
If you are using SQL Server 2008 R2, you can use a second computer running SQL Server 2008 R2 to
implement database high availability; two similar techniques are database mirroring and 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
mirroring requires a copy of the database and log files on both the live and standby servers.
4-13
Log shipping is similar to database mirroring, but it does not guarantee transactional consistency, and it
cannot perform automatic failover.
If you are using SQL Server 2012, database mirroring has been deprecated in favor of a similar but
improved technology called AlwaysOn availability groups. AlwaysOn availability groups can have up
to five copies, or replicas, of a database on different SQL Servers to provide redundancy and failover
capabilities. AlwaysOn availability groups are only available with SQL Server 2012 Enterprise edition.
You can use additional computers running SQL Server to implement a form of server high availability
known in SQL Server 2008 R2 as failover clustering and in SQL Server 2012 as AlwaysOn failover
cluster instances (FCI). 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:
o
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.
Additional Reading: For more information about high availability with SQL Server, see
High Availability with SQL Server 2008 R2 at http://go.microsoft.com/fwlink/?linkid=299535
For more information about high availability in SQL Server 2012, see High Availability Solutions
(SQL Server) at http://go.microsoft.com/fwlink/?linkid=299536
For more information about tuning SQL Server 102 for SharePoint 2103, see Tuning SQL Server
2012 for SharePoint 2013 Jump Start at http://go.microsoft.com/fwlink/?Linkid=299537
Supporting SharePoint Online and Hybrid Deployments

If your organization is considering a SharePoint
Online deployment, it is important to examine the
broader options of implementing part of or the
entire Microsoft Office 365 offering. You should
consider the following questions:
Does your organization plan to have or retain

on-premise AD DS domain controllers for user
and computer management?
Does your organization plan to implement

cloud-based SharePoint (SharePoint Online)
only, or have a mix of cloud-based and onpremises (hybrid) SharePoint deployments?
If your organization is considering a hybrid deployment, do you want single sign-on capabilities for
AD DS users to SharePoint Online?
If you plan to retain an on-premise AD DS environment and you want single sign-on capabilities for your
AD DS users, you will need to implement Active Directory Federation Services (AD FS) 2.0. AD FS is a
component of Windows Server 2008 and later, and enables you to federate authentication to a trusted
third-party so that the third-party can use your account store (in this case, the on-premise AD DS) to
authenticate users to resources of the third-party (in this case, Office 365 is the third-party). This is
referred to as a relying party trust.
In addition, for single sign-on, you must configure Active Directory synchronization between your onpremises AD DS environment and SharePoint Online. The synchronization can be set up after AD FS is
configured, and it uses a separate computer to perform the synchronization tasks.
Note: For single sign-on, your users must have a user principal name (UPN) suffix that is
under a DNS domain name that can be publically registered.
Discussion: Advantages of a SharePoint Online Deployment

What advantages does a SharePoint Online
deployment have over an on-premises
deployment?
Lesson 3
SharePoint Farm Topologies
4-15
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 organizations.
Using SharePoint 2013, 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.
Lesson Objectives
Identify suitable topologies for single farms.
Explain options for multiple farm topologies and cross-farm services.
Identify topologies for multiple farms to support content publishing.
Describe the support for multi-tenancy in SharePoint 2013.
Describe reasons for implementing Request Manager in SharePoint 2013.
Describe the components of a SharePoint 2013 hybrid solution.
Single Farm Topologies

In SharePoint 2013 farms, there are three server
roles to consider:
Web Front End (WFE) servers. This role has

SharePoint 2013 installed; it hosts web
applications and responds to requests from
browsers. WFE servers will be the destination
of the URL a user types in.
Application servers. This role has SharePoint

2013 installed and performs tasks associated
with service applications in SharePoint 2013.
Typically, users dont connect directly to this
role.
Database servers. This role has SQL Server installed and hosts the different databases required to
support a SharePoint farm, including the farm configuration database, service application databases,
and content databases.
When deploying a SharePoint 2013 farm, you can choose that some or all of the roles coexist on one
server, or that all roles should be on dedicated servers to create your farm topology. 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.
Note: With the exception of the database server, every server role in a SharePoint farm is
simply a server running SharePoint. The term server role simply indicates that you can distribute
various SharePoint services so that specific servers have specific responsibilities.
There are three categories of farm topologies:
Small farms. These farms typically have between three and 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 six and 10 servers, separated into three tiers.
In medium farms, service applications are often spread out across 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.
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.
After you configure more than one WFE server in a farm, it is possible to use network load balancing
(NLB) to spread browser requests across the available WFE servers. This approach provides performance
improvements and high availability capabilities. In most cases, NLB can adjust where inbound requests are
directed if there is a server failure. You can implement NLB by using the Windows NLB feature, included in
Windows Standard, Enterprise, and Datacenter editions, or by using a third-party hardware load balancer.
Note: Server groups are only a design conceptthere is no such management object in a
SharePoint 2013 farm.
Additional Reading: For more information about server farm topologies, see the
Topologies for SharePoint 2013 model in the architecture section of Technical Diagrams for
SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299540 and the diagram at
Multiple Farm Topologies and Cross-Farm Services

In SharePoint 2013, 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 toboth 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.
4-17
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 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. Because of the increased number of servers required, multiple farm topologies are a good
candidate for virtualization.
Multiple Farms for Content Publishing

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.
In an authoring farm, content authors can make
changes to content; often, these types of farms are
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
items are published into general circulation.
In a production farm, readers can 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.
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: Typically, the use of different server farms for authoring or staging purposes is only
suitable for publishing content, not for collaboration content.
Some organizations will use additional farm environments, such as a development farm and a testing
farm, 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 Design content deployment topology (SharePoint Server 2010) at
http://go.microsoft.com/fwlink/?LinkID=200874 The principles in this article are still relevant for
SharePoint 2013.
Discussion: Advantages of Separate Farms for Content Publishing

What are the advantages of having a separate
farm for content publishing?
Multi-Tenancy Environments
SharePoint 2013 builds on the improved options
for hosting providers added in SharePoint 2010.
Improvements in logical architecture enable you
to implement farm deployments that use a multitenancy 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 2013. 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 tenant organizations 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.
Multi-tenancy uses the following features:
Multiple web applications or host-header site collections to accommodate many disjoint namespaces.
Site subscriptions to enable grouping and administration of site collections by tenant. Site
subscriptions also help with service application connections.
Service application partitioning to store service application data separately for different tenants.
What Is Request Manager?

Request Manager is a new feature in SharePoint
2013 that helps manage the way WFE servers
handle browser requests. Request Manager
enables administrators to implement rules that can
perform the following:
Direct a request to a healthier or less loaded

WFE server.
Direct a request to a preferred server

configured by an administrator.
Ignore certain types of request, such as a

search crawler request, when the WFE server is
very busy.
Direct requests from a specific IP address range to a specific range of WFE servers.
Identify and block harmful requests.
4-19
Request Manager uses a health score based on resource load for each WFE server in order to help direct
requests to better performing servers, and administrators can create machine pools that are a collection of
servers able to fulfill routing rules. You can prioritize routing rules by using execution groups. There are
three execution groups that can contain routing rules, but execution groups are always evaluated in order.
Additional Reading: For more information about Request Manager, see Configure Request
Manager in SharePoint 2013 at http://go.microsoft.com/fwlink/?linkid=299545
SharePoint 2013 Hybrid Deployments

You can use a SharePoint 2013 hybrid deployment
in order to leverage the capabilities of SharePoint
Online and still give users the ability to access
internal corporate line-of-business (LOB) data
through the SharePoint Online environment.
The SharePoint Online BCS hybrid solution
accesses LOB data by connecting to a reverse
proxy, which publishes a BCS service application
from your on-premises SharePoint 2013 farm. In
this way, the LOB data stays on the internal
corporate network and the reverse proxy protects
the on-premise SharePoint environment from
unauthorized Internet access.
There are several supporting components that provide this hybrid capability, including:
SharePoint Online BCS Runtime Service Online. SharePoint Online provides a BCS instance for
managing external data connectivity.
SharePoint Online Secure Store Service. In a SharePoint hybrid solution, the secure store service must
hold an SSL certificate that authenticates the SharePoint Online request to the reverse proxy.
Azure Access Control Service. This service performs authentication when a user logs on to a SharePoint
Online site. It looks up credentials in the Microsoft Online Directory Service (MSODS), which has been
synchronized with the on-premises Active Directory accounts.
On-premises BCS instance. The BCS service application enables SharePoint to connect and retrieve
data from external LOB systems.
On-premises Secure Store service. This service application is needed in a BCS hybrid deployment to
store the mapping of users domain credentials to the credentials that are used to access the LOB
system data.
Note: The SharePoint BCS hybrid solution supports only the OData protocol.
Additional Reading: For more information about hybrid SharePoint 2013 deployments,
see Hybrid for SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299521
Lesson 4
Mapping a Logical Architecture Design to a Physical

Architecture Design
4-21
There is a strong link between the logical architecture of SharePoint 2013 and the physical architecture of
SharePoint 2013. 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.
Lesson Objectives
Identify existing management requirements, and their impact on SharePoint.
Identify links between logical and physical architectures in SharePoint.
Describe additional SharePoint topology requirements.
Document the physical design.
The Impact of Business Requirements on Physical Design

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:
Office Web App servers are required in

addition to your SharePoint farm servers if
you plan to deploy Office Web Apps.
Deploying Workflow Manager often requires additional server hardware to process the workload.
Security requirements or policies may exist that govern how servers can transmit data, or there may
be configuration requirements for web servers in perimeter networks.
Authentication requirements may exist that the SharePoint solution must meet, such as two-factor
authentication devices.
Firewall policies that can restrict placement of domain controllers in the perimeter network or prevent
logon traffic from successfully passing.
Network usage on shared network segments must be accounted for when you calculate network
usage and bandwidth requirements. You must include this usage in your calculations and your
performance testing.
SQL Server database administrators (DBA) may be required by your organization to administer the
SharePoint database servers instead of SharePoint administrators.
Mapping Logical Architecture Design to Physical Specifications

After you establish 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.
Logical design requirements
Impact on physical specifications
Size of repository
For large content collections (corpus over 40

million items) or multiple-farm scenarios, this
repository may require a dedicated search farm.
Number of web applications
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.
Quantity of content
As content demand increases, you may require

additional databases to store content beyond a
manageable limit, such as 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)
Mappings for host headers and

alternate access
Host header and alternate access mapping use

requires additional DNS record configuration. You
may need to change internal DNS, Internet DNS,
or both.
Management of digital assets
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.
Identifying Network Placement

In addition to designing the number of farms that
you require and sizing the farm(s), you must
consider farm placement.
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 Internet
to corporate users, business partners in an extranet
scenario, or publiclythere are options for
deployment of the farm and Active Directory. The
following table describes the server placement
options and corresponding considerations.
Farm placement
Active Directory
placement
Internal network
Internal network
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.
Perimeter network
Internal network
Authentication traffic must pass

back from the WFE servers to the
domain controllers in the internal
network.
Split WFE and

application servers in the
perimeter network,
computers running SQL
server on the internal
network.
Splitdomain controllers
for internal domain in
both internal and
perimeter 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
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).
Considerations
Note: You should choose an Active Directory and farm placement configuration that best
meets your organizations security and authentication requirements.
4-23
Documenting Physical Architecture

As part of your design process, it is important to
document your SharePoint 2013 solution design in
order to clearly identify requirements to key
stakeholders and reach agreement on what should
be delivered as part of the solution.
You should include the following elements as part
of your design documentation:
Logical architecture design
Service application architecture design
Physical design
Security and authentication design
Metadata design
Application design
Search
Business intelligence
Content management
Operations and maintenance
Business continuity
However, this will often be an iterative process because aspects of your business intelligence design may
affect your logical architecture design, which in turn may affect your physical architecture design.
With physical architecture, it is best to identify farm servers, farm topologies, network placement, domain
controller placement, and Internet access requirements diagrammatically in order to more easily relate to
the farm requirements when performing the deployment. However, it is also important to document
aspects that may not suit a diagram, such as server hardware, server role details, and software
requirements, on a spreadsheet as a clear reference.

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.
Your whole class will work together to discuss the requirements and complete the SharePoint 2013
Physical Architecture Planning worksheet. Your instructor will facilitate your discussions.
Objectives
1.
Map the logical architecture requirements design for Contoso to a physical architecture.
2.
Develop a physical architecture design.

o
User name: admin
Passw0rd: Pa$$w0rd
Exercise 1: Designing a Physical Architecture

Scenario
Based on the output from the Logical Architecture Design, you will now identify the physical architecture
to support the business requirements. This must reflect the security and service availability requirements
highlighted in the physical systems-specific business requirements. The output from the logical
architecture design effort is available for you to review.
1. Develop a Physical Architecture Design Document
Task 1: Develop a Physical Architecture Design Document
In the E:\Mod04\Starter folder, read the business requirements in the Contoso Physical
Architecture Requirements.docx file and the logical architecture designs, found in SharePoint
2013 Logical Architecture Planning Worksheet_Solution.xlsx and SharePoint 2013 Logical
Complete the SharePoint 2013 Physical Architecture Planning Worksheet.xlsx worksheet.
Results: After completing this exercise, you will have a complete SharePoint 2013 Physical Architecture
Planning worksheet.
Exercise 2: Develop a Physical Architecture Design Diagram

Scenario
The SharePoint 2013 Physical Architecture Planning Worksheet has been agreed and signed off, but to
complete the documentation, you need to complete the SharePoint 2013 Physical Architecture Diagram
Office Visio diagram.
1. Develop a Physical Architecture Design Diagram
Task 1: Develop a Physical Architecture Design Diagram
Open the Office Visio SharePoint 2013 Physical Architecture Diagram.vsd file.
Complete the diagram, in line with your SharePoint 2013 Physical Architecture Planning Worksheet.
Results: After completing this exercise, you will have a complete Physical Architecture Design diagram.
In this module, you learned about designing physical components, such as hardware and software
requirements, and you learned about designing the supporting components for SharePoint 2013, such as
Active Directory and IIS. You also examined various SharePoint farm topologies and identified how to map
logical architecture and physical architecture together.
Review Question(s)
Question: Which SQL database recovery model is not suitable for SharePoint 2013
databases?
Question: Can you add SSL certificates to SharePoint web applications by using Central
Administration?
Question: In an organization with two collaborative SharePoint farms, is it possible to share
content types from Farm A to Farm B and simultaneously share content types from Farm B to
Farm A?
Test Your Knowledge
Question
Which supporting component is required to support single sign-on with on-premises
Active Directory and SharePoint Online deployments?
Active Directory Rights Management Services (AD RMS).
Active Directory Federation Services (AD FS).
Active Directory Lightweight Directory Services (AD LDS).
Active Directory Certificate Services (AD CS).
A reverse proxy.

5-1
Module 5
Installing and Configuring SharePoint Server 2013
Contents:
Module Overview
5-1
Lesson 1: Installing SharePoint Server 2013
5-2
Lab A: Deploying and Configuring SharePoint Server 2013 Part One
5-16
Lesson 2: Scripting Installation and Configuration
5-19
Lesson 3: Configuring SharePoint Server 2013 Farm Settings
5-24
Lab B: Deploying and Configuring SharePoint Server 2013 Part Two
5-33
5-39
Module Overview
After you design and plan your logical and physical architectures for a Microsoft SharePoint Server 2013
deployment, the next installation steps are to implement the deployment design and specify
configuration settings for the deployment.
In this module, you will learn about installing SharePoint 2013 in various topologies. You will learn how to
configure farm settings, and how to script the installation and configuration of SharePoint 2013.
Objectives
Install SharePoint 2013.
Configure SharePoint 2013 farm settings.
Script the installation and configuration of SharePoint 2013.
Lesson 1
Installing SharePoint Server 2013
5-2
The deployment stages for SharePoint 2013 include preparation, installation, and configuration of your
In this lesson, you will learn how to prepare for a SharePoint 2013 deployment, how to track your
SharePoint 2013 installations for auditing purposes, and how to install language packs. You will also learn
about the different deployment topologies and high-level deployment tasks for SharePoint 2013, and the
differences between using a wizard-based or manual approach when configuring your farm.
Lesson Objectives
Prepare to install SharePoint 2013.
Configure installation tracking and blocking in SharePoint 2013.
Understand and install SharePoint 2013 language packs.
Understand the different SharePoint 2013 deployment topologies.
Describe the difference between wizard-based and manual farm configuration in SharePoint 2013.
Accounts Required for SharePoint 2013 Installation

This topic provides details of the service accounts
and administrative accounts that you need when
deploying a SharePoint 2013 farm.
SharePoint, SQL Server, and Active

Directory
SharePoint has close relationships with and
dependencies on Microsoft SQL Server and Active
Directory.
Active Directory provides identity and

authentication services. In other words, it stores
user accounts (user names and passwords) and
validates account logons. These services support users logging on to SharePoint sites. They also support
the accounts used by SharePoint and SQL services themselves.
SQL Server stores almost all of the configuration and content of a SharePoint farm. SQL Server services,
like all Windows services, run using an identity.
SharePoint services also run with Active Directory credentials. The credentials are used by SharePoint to
access data in SQL Server. These accounts must have SQL logins so that SQL can authorize the access.
These SQL logins are created automatically by SharePoint during setup and the creation of web
applications.
Service and administrative accounts
Before installing SharePoint, you must ensure that there are appropriate accounts, logins, and permissions
to support the interdependencies between SharePoint, SQL Server, Active Directory, and the SharePoint
server itself.
SQL Server service account
SQL Server services use identities, or accounts. Like most Windows services, you can use a special identity
such as System, Network Service, or Local Service, but it is a highly recommended best practice to use a
domain user account. If SQL Server is installed on a different computer to where SharePoint is installed, it
is required to use a domain account.
Setup user account
The setup user account is used by a human being to install and configure SharePoint. During setup and
configuration, SharePoint creates SQL databases and logins, and modifies the server itself (for example,
creating local groups). SharePoint setup and configuration uses the credentials of the setup user account
to perform such tasks, so it must be a securityadmin and dbcreator on the SQL Server, and it must be a
member of the local Administrators group. It must also be a member of the db_owner fixed database role
on any databases affected by any Windows PowerShell cmdlets that you run.
The only SQL login that you must manually create is the login for the setup user account, which actually
performs the initial setup of the farm.
Server farm account
During installation and configuration, the setup user account assigns an account to the SharePoint farm,
which is the service account representing the SharePoint farm.
The server farm account is also referred to as the database access account and is used by SharePoint to
configure and manage the server farm. It is also the identity used by the Central Administration sites
application pool, and the identity used by the Timer service.
The SharePoint Products Configuration Wizard automatically assigns the account the permissions it needs.
The server farm account is automatically added as a SQL Server login on the computer that runs SQL
Server. The account is added to the following SQL Server security roles:
dbcreator fixed server role
securityadmin fixed server role
db_owner fixed database role for all SharePoint databases in the server farm
Application pool accounts
Each web application runs in an application pool. The application pool identity is a domain user account
that is functionally equivalent to a service account, with permissions to access the content database for
the web application on the SQL Server.
Service applications, such as Search, are also web applications. Therefore, they also run in an application
pool with a domain user identity.
Web and service application pool accounts are automatically granted the permissions they need during
the provisioning of the application.
Installing SharePoint 2013 Prerequisites

You must install some software prerequisites
before installing SharePoint Server 2013;
otherwise, the SharePoint installation will fail.
These prerequisites can be installed through a
variety of methods.
Install prerequisites using the Microsoft

SharePoint Products Preparation Tool
The Microsoft SharePoint Products Preparation
Tool, also known as the prerequisite installer, can
automatically download and install all of the
prerequisites for you. As part of the prerequisite
installation process, the tool needs to connect to
the Microsoft Download Center, so Internet access is required.
To run the Microsoft SharePoint Products Preparation Tool:
5-4
1.
Log on as the Setup user account.
2.
In the folder where you downloaded the SharePoint 2013 software, locate and run
PrerequisiteInstaller.exe.
3.
On the Welcome to the Microsoft SharePoint Products Preparation Tool page, click Next.
4.
On the License Terms for software products page, review the terms, select the I accept the terms
of the License Agreement(s) check box, and then click Next.
5.
On the Installation Complete page, click Finish.
During the scanning and installation process, the tool scans for each prerequisite. If a prerequisite is not
found, the tool downloads, installs, and configures the prerequisite. If an error occurs, such as a download
failure, the tool stops and produces an error message that indicates which prerequisite failed. You can find
details of the failure in the error log, which is located in the %TEMP% folder. The tool displays a link to the
log. After you fix the issue, you must rerun the tool and repeat the process until all prerequisites are
successfully installed and configured.
Install prerequisites from a network share
In environments where installing the prerequisites directly from the Internet is not a viable solution, you
can alternatively choose to download the prerequisites to a computer that is connected to the Internet
and then install the prerequisites from a network share using the Microsoft SharePoint Products
Preparation Tool.
This solution is ideal for companies that want to install SharePoint 2013 on servers that are not connected
to the Internet, such as in a pre-production test or development environment. This solution also provides
greater consistency and control of a centralized deployment image set.
Identify, download, combine, and share the prerequisites
Perform the following steps to identify, download, and combine the prerequisite files to a shared network
location for installing SharePoint 2013 on all your farm servers.
To identify and download the prerequisites:
1.
Refer to the Hardware and software requirements for SharePoint 2013 TechNet article at
http://go.microsoft.com/fwlink/?Linkid=299548 which lists all the required and optional software for
SharePoint 2013. This document also provides the download location for each prerequisite that is
available for download on the Internet.
2.
From a command prompt, navigate to the root of the SharePoint 2013 installation media or local
folder location.
3.
At the command prompt, type PrerequisiteInstaller.exe /?, and then press Enter. This displays a list
of the command-line options and switches and their corresponding arguments for installing a
prerequisite from the command line.
4.
Verify that you have an accurate list of the required software. Compare the output from the
prerequisite installer to the list of prerequisites in step 1.
5.
Download the prerequisites to a computer that has Internet access.
To combine prerequisites in a central location:

1.
Create a shared folder on a computer that can be accessed by the servers on which the prerequisites
will be installed.
2.
Copy the files that you downloaded from the Internet to the shared folder.
Installer switches and arguments
By using the PrerequisiteInstaller.exe tool at a command prompt with switches and arguments, you gain
greater control over which prerequisite software versions are installed and where they are installed from.
You can also use multiple switches and argument pairs if needed. Each switch identifies a prerequisite to
install, and the corresponding argument identifies the action to take and the location of the prerequisite.
You use the switch and argument pair by using the following syntax:
/switch: <path>
Where:
/switch is a valid switch to identify one of the software prerequisites. For example, /SQLNCli: is the
switch for the Microsoft SQL Server 2008 R2 SP1 Native Client.
<path> is the path to a local file or network share. For example, "C:\prerequisites\sqlncli.msi" or
"\\server01\prereqsshare\sqlncli.msi".
You separate each switch and its corresponding argument by a colon and a space, with the argument
inside quotation marks. You can use the switch and argument directly at the command prompt with
prerequsiteinstaller.exe, or you can create an arguments text file and have them read from there.
Install the SharePoint 2013 prerequisites from a network share by using the command
prompt
You can install one or more of the prerequisites from the command line using the following procedure:
1.
On the Start screen, type command, right-click Command Prompt, and then on the AppBar, click
Run as administrator.
2.
Navigate to the SharePoint 2013 source directory on the network share.
3.
Type the prerequisite program switch and corresponding argument for the program that you want to
install, and then press Enter.
Example: PrerequisiteInstaller.exe /SQLNCli: \\server01\prereqsshare\sqlncli.msi

Note: To install more than one prerequisite, type each switch and argument pair. Be sure to
separate each pair by a space. For example:
PrerequisiteInstaller.exe /IDFX: "\\<path>\Windows6.1-KB974405-x64.msu"
/sqlncli:"\\<path>\sqlncli.msi" /Sync:"\\<path>\Synchronization.msi"
Install the SharePoint 2013 prerequisites from a network share by using an

arguments file
5-6
You can install all the SharePoint 2013 prerequisites by using an arguments file that contains all the
required switches and paths to the software prerequisites. The arguments file can be stored on a network
shared folder.
To create the arguments file:
1.
Use Notepad to create a new text document named PrerequisiteInstaller.Arguments.txt.
2.
Save the file to the same folder where PrerequisiteInstaller.exe is located. This file will contain the
switches and arguments that are used when you run the Microsoft SharePoint Products Preparation
Tool.
3.
Use Notepad to edit PrerequisiteInstaller.Arguments.txt, and provide file paths to the installation
source for each prerequisite switch by using the following syntax:
/switch: <path>
Where /switch is a valid switch to identify one of the software prerequisites, and <path> is the path of the
network share installation source.
Reader Aid: Do not include carriage returns in your file; if you do, it will not run
successfully.
4.
After you finish editing PrerequisiteInstaller.Arguments.txt, save your edits, and then verify that this
file is in the same location as the PrerequisiteInstaller.exe file.
To install the prerequisites using an arguments file:

1.
At the command prompt, run PrerequisiteInstaller.exe. (If you are prompted to click Finish to
restart the system, do not do so. Instead, click Cancel.)
2.
Restart the system manually.
3.
At the command prompt, type PrerequisiteInstaller.exe, and then press Enter.
Configure SQL Server Client Aliases

If you have blocked the default listening ports on
the SQL Server, you need to configure SQL Server
client aliases on all your web front-end servers and
application servers. These aliases are required on
all servers that need to communicate with your
SQL Server. This is also useful for hot-switching
when you have fault tolerance enabled on your
database servers.
To create these aliases, you can either install two

SQL Server client components, which can be
installed by running Setup from SQL Server on the
SharePoint 2013 web servers and application
servers, or you can use the SQL Server Client Network Utility (cliconfg.exe) which is provided with
Windows Server 2012 and Windows Server 2008 R2. There are both 32-bit and 64-bit versions of this
utility. Windows keeps separate lists of SQL aliases, one used by 32-bit applications and the other by 64-
5-7
bit, maintained by their respective versions of cliconfg.exe. These lists are completely independent, and
are only accessible by applications compiled with the same bit width. As such, you need to run both
utilities, located here:
32-bit version C\Windows\SysWOW64
64-bit version C\Windows\System32
To configure a SQL Server client alias using the SQL Server Client Network Utility:
1.
Verify that the user account that is performing this procedure is a member of either the sysadmin or
the serveradmin fixed server role.
2.
On the target server, on the Start screen, click Computer.
3.
Browse to C:\Windows\System32.
4.
Double-click cliconfg.exe.
5.
In the SQL Server Client Network Utility window, click the Alias tab.
6.
On the Alias tab, click Add.
7.
In the Server alias box, type the name for your alias, for example SQL_Alias1.
8.
Under Network libraries, click TCP/IP.
9.
In the Server name box, type the name of your SQL Server computer, and then click OK.
10. Close the SQL Server Client Network Utility.

11. In Computer, browse to C:\Windows\SysWOW64.
12. Repeat steps 4 to 10.
13. Repeat these steps on all your SharePoint 2013 web servers and application servers.
Configure Installation Tracking

Farm administrators who manage their
organizations SharePoint 2013 deployment at the
farm level may be unaware of any other
authorized or unauthorized deployments of
SharePoint 2013 that exist in their enterprise
environment.
There is a way for you to be able to track these
other deployments and even to block rogue
installations of SharePoint 2013.
Track installations of SharePoint 2013
Service Connection Points (SCPs) are Active

Directory objects that contain information about services in your environment. It is the service itself that
publishes this information about its existence. This information is stored in Active Directory as a marker so
that a client application can find and connect to the appropriate service. The marker holds the URL for the
Application Discovery and Load Balancer Service. This service provides information about the farms
topology to users of the farm services.
You can also use these markers to track SharePoint 2013 installations in your organization.
5-8
To do this, you must create an Active Directory container by using ADSI Edit, and then set permissions on
the container. This marker is set on a domain basis, so you need to create a container in each domain that
you plan to track installations for in your infrastructure.
When a user in one of these domains installs SharePoint 2013 by using the SharePoint Products
Configuration Wizard, the marker is set and the installation can be tracked. For this to work, you must
give Write permissions on the container to any user who could run the SharePoint Products Configuration
Wizard.
Create a service connection point container to track installations

You can use ADSI Edit to create the Active Directory container and to set the write permissions for the
appropriate users.
To create a service connection point container:
1.
On the domain controller, on the Start screen, click Administrative Tools, and then double-click
ADSI Edit.
2.
On the Action menu, click Connect to, and connect to the domain that you want to use.
3.
In the console tree, expand the connection, expand the domain name, and then click CN=System.
4.
In the details pane, right-click in the white area, click New, and then click Object.
5.
In the Create Object dialog box, in the Select a class box, click container, and then click Next.
6.
In the Value box, type Microsoft SharePoint Products as the container name, and then click Next.
7.
Click Finish to create the container.
8.
Right-click the container (CN=Microsoft SharePoint Products), and then click Properties.
9.
On the Security tab, click Add.
10. In the Select Users, Computers, Service Accounts, or Groups box, add the users that you want to
write to this container, and then click OK.
Best Practice: If a user who cannot write to this container installs SharePoint Server 2013,
no new entry will be created. Therefore, it is considered a best practice to provide the Write
permission to all authenticated users so that you can track all the objects.
11. In the Group or user names box, select the names that you previously added, and then under the
Permissions box, click Advanced.
12. In the Permission entries box, select the names that you previously added, and then click Edit.
13. In the Permission Entry for Microsoft SharePoint Products dialog box, in the Permissions box,
select the Allow check box for Create serviceConnectionPoint objects, and then click OK.
14. Click OK, and then click OK again.
15. Close ADSI Edit.
Block installations of SharePoint 2013

In order to block users from installing SharePoint Server 2013, you can add the following registry key
manually or by using Group Policy:
HKLM\Software\Policies\Microsoft\Shared Tools\Web Server Extensions\15.0\ SharePoint\DWORD
DisableInstall
To block installations, set the DWORD DisableInstall value to 1.
5-9
After you set this registry key and a user attempts to install SharePoint Server 2013, the following error
message displays:
Installation of this product is not permitted on this computer. Please contact your network administrator for
more details.
Installing Language Packs

If you are working in an environment that needs
to support multiple languages, you must install
language packs for SharePoint Server 2013.
Language packs consist of language-specific site
templates you install on your farms web and
application servers. Multiple language packs can
be installed on the same server.
You can use language packs to create multilingual deployments of SharePoint 2013 without
needing to perform separate SharePoint 2013
installations. Language packs are useful in
multinational organizations where one SharePoint
2013 farm might support users from several different countries who need to access websites that are
available in several different languages.
When you create a new website, you can select the language that you want the new site to be presented
in after you deploy the required language packs. A language pack makes changes to items on a site, such
as the toolbars, navigation areas, buttons, and menu and list items.
Note: After you create a site in a specific language, you cannot change the site language.
Language pack installation

Language packs need to be downloaded from the Microsoft Download Center before they can be
installed on your servers.
Note: Applying a language pack does not change the language of the installed SharePoint
2013 product, or the language of its administration features.
You must download a language pack for each language that you want to support with SharePoint. There
is no single package that contains all the language packs.
Best Practice: The downloaded files for different languages may have the same file name.
If this situation occurs, rename the downloaded files or save them to separate folders so that you
do not unintentionally overwrite a previously downloaded language pack.
Language files
Before installing SharePoint 2013 language packs, you must ensure that the language files for the
Windows operating system have been installed. Windows includes language files for many languages in
its default configuration. However, if the languages you are supporting include any of the following, you
must manually install the Windows language files:
5-10 Installing and Configuring SharePoint Server 2013
East Asian languages, including Chinese, Japanese, and Korean
Complex script and right-to-left-oriented languages, including Arabic, Armenian, Georgian, Hebrew,
the Indic languages, Thai, and Vietnamese
You can install Windows language files by using the Clock, Language, and Region application in Control
Panel.
To install a language pack for SharePoint 2013 and run the SharePoint Products Configuration Wizard:
1.
Log on as the Setup user account.
2.
In the folder where you downloaded the language pack, double-click the executable file, for example
sharepointlanguagepack.exe.
3.
On the Read the Microsoft Software License Terms page, review the terms, select the I accept the
terms of this agreement check box, and then click Continue.
The Setup wizard runs and installs the language pack.

4.
Verify that the check box is selected to run the SharePoint Products Configuration Wizard now,
and then click Close.
Note: If you do not rerun the SharePoint Products Configuration Wizard after you install a
language pack, the language pack will not be installed correctly.
5.
On the Welcome to SharePoint Products page, click Next.
6.
In the SharePoint Products Configuration Wizard dialog box, click Yes on the message that some
services might have to be restarted during configuration.
7.
On the Configuration Successful page, click Finish.
Note: After you install a new language pack and rerun the SharePoint Products
Configuration Wizard, you must deactivate and then reactivate any language-specific features
before you use the new language pack.
Uninstalling language packs
Language packs can be uninstalled through Control Panel. When you remove a language pack, the
language-specific site template is removed from the server on which it is installed. Therefore, if you have
several sites that use that particular language-specific site template, they will no longer be usable, and
users will receive an internal server error page when they attempt to access one of those sites. If you
decide to uninstall SharePoint 2013, you must uninstall all language packs first before uninstalling
SharePoint 2013.
To uninstall a language pack:
1.
On the Start screen, click Control Panel.
2.
Under Programs, click Uninstall a program.
3.
In the list of currently installed programs, select the language pack you want to uninstall and then
click Uninstall.
4.
Click Yes to confirm that you want to remove the program.
5.
On the Warning page, click OK.
6.
On the dialog box informing you that the language pack has been successfully uninstalled, click
Close.
Note: You cannot remove the language pack for the same version of SharePoint that you
have installed on the server.
Installation Topologies
SharePoint 2013 can be installed on one or more
servers and in several different topologies, each of
which has its own characteristics and
requirements.
Installing SharePoint 2013 on a single

server with a built-in database
If you are only evaluating SharePoint 2013
features, or if you plan to deploy a small number
of websites and maintain a low administrative
overhead, installing SharePoint 2013 on a single
server with a built-in SQL Server Express database
is the best solution for you.
5-11
When you install SharePoint 2013 in this scenario with default settings, the setup process installs both
SharePoint 2013 and SQL Server 2008 R2 SP1 Express Edition. When you run through the SharePoint
Products Configuration Wizard, the configuration database and content database are created for your
SharePoint site, and your first site collection and the Central Administration website are also created.
However, there are some caveats when deploying this kind of topology; for example, you cannot use this
topology for a workgroup environment and you cannot deploy it on a domain controller. Additionally, the
SQL Server Express database cannot grow to any larger than 10 gigabytes (GB), and you cannot use user
profile synchronization; that topology requires a server farm deployment.
The following are the high-level steps to install and configure SharePoint 2013 on a single server with a
built-in database:
1.
Run the Microsoft SharePoint Products Preparation Tool, which installs all prerequisites to use
SharePoint 2013.
2.
Run Setup, which installs Microsoft SQL Server 2008 R2 SP1 Express Edition and the SharePoint
product.
3.
Run the SharePoint Products Configuration Wizard, which installs and configures the configuration
database, the content database, and installs the SharePoint Central Administration website. This
wizard also creates your first SharePoint site collection.
4.
Configure browser settings.
5.
Perform post-installation steps.
Additional Reading: For more information, see Install SharePoint 2013 on a single server
with a built-in database at http://go.microsoft.com/fwlink/?Linkid=299549
Installing SharePoint 2013 on a single server with SQL Server
The advantage of using this topology for your SharePoint deployment is that you initially only install
SharePoint 2013 and SQL Server on a single server, but you can later scale out your farm to a two-tiered
or three-tiered farm topology by adding servers to the farm at a future date.
So, like the single-server with built-in database topology, this topology is useful in evaluation or small
production environments. However, unlike the single-server with built-in database topology, this topology
has the potential to grow and develop into a larger and more complex farm topology.
The following are the high-level steps to install and configure SharePoint 2013 on a single server with SQL
Server:
1.
Run the Microsoft SharePoint Products Preparation Tool, which installs all the prerequisites for
SharePoint 2013.
2.
Run Setup, which installs the binaries, configures security permissions, and edits registry settings for
SharePoint 2013.
3.
Run the SharePoint Products Configuration Wizard, which installs and configures the configuration
database, installs and configures the content database, and installs the SharePoint Central
Administration website.
4.
Configure browser settings.
5.
Configure the farm using one of these two approaches:
6.
Run the Farm Configuration Wizard, which configures the farm, creates the first site collection,
and selects the services that you want to use in the farm.
Manually configure the farm settings using Central Administration or Windows PowerShell. For
more information, see Farm Configuration Wizard vs. Manual Farm Configuration later in this
lesson.
Perform post-installation steps.
Additional Reading: For more information, see Install SharePoint 2013 on a single server
with SQL Server, at http://go.microsoft.com/fwlink/?Linkid=299549
Installing SharePoint 2013 across multiple servers for a three-tier farm
This three-tiered topology becomes the basis for deploying any more complex SharePoint farm solutions.
Typically, you separate farms with three or more servers into three tiers, according to server roles, as
follows:
Web Tier. Contains servers assigned the Web Application Server role. Typically, servers of this type are
referred to as Web Front Ends (WFEs). These are the servers responsible for serving content to end
users over SharePoint webpages and web services. These servers can also be configured to host
dedicated query components.
Application Tier. Contains servers assigned the Search Crawl role, the Search Query role, and servers
hosting the farms service applications. The servers in this tier host services such as crawl and query
components and any other farm services that need specific resources or need to be isolated from the
Web Tier.
Database Tier. Contains servers hosting the farms SQL Server instance(s). The servers in this tier host
the farms databases in SQL Server. You can further extend this tier by adding more database servers
to provide some form of high availability, such as database mirroring or failover clustering.
5-13
Every server farm configuration is unique. You must consider your organizations specific requirements,
resources, and constraints when designing the topology for your SharePoint 2013 farm.
The following graphic displays a typical three-tier SharePoint farm.
FIGURE 5.1:THREE-TIER SHAREPOINT FARM

The following are the high-level tasks for the three-tier SharePoint 2013 deployment topology:
1.
Ensure that you have done all the planning and preparatory work, such as verifying hardware and
software requirements.
2.
Install the required software updates on all servers that will be part of the farm.
3.
Install the SharePoint 2013 prerequisites on servers in the application and web tiers.
4.
Install SharePoint 2013 on the application server and the web servers.
5.
Create and configure the SharePoint farm.
6.
Provision services.
7.
Complete post-deployment tasks as required.
Additional Reading: For more information, see Install SharePoint 2013 across multiple
servers for a three-tier farm at http://go.microsoft.com/fwlink/?Linkid=299550
Farm Configuration Wizard vs. Manual Farm Configuration

After you complete the setup and initial
configuration of SharePoint 2013 and you have
created the SharePoint Central Administration
website, you are ready to create your farm and
sites, and to select services. These steps can either
be performed by using the Farm Configuration
Wizard, or you can perform these tasks manually.
When you first open Central Administration, you
will be asked whether you want to run the Farm
Configuration Wizard.
Using the Farm Configuration Wizard
The Farm Configuration Wizard is a SharePoint

2013 tool that is designed to help you complete some of the common tasks necessary to get your farms
first SharePoint site up and running, as well as the services it needs to deliver content and functionality to
end users. It is available to your farms administrators from the SharePoint Central Administration website.
The advantage of using the Farm Configuration Wizard to configure your farm is obvious; it is a simple
automated process using an easy-to-understand graphical user interface; therefore, you do not need to
use other tools such as Central Administration and Windows PowerShell cmdlets. The disadvantage of
using the wizard is you do not have quite as much control of the tasks in the process.
The Farm Configuration Wizard is particularly well suited to situations where you are configuring a
SharePoint farm for testing, training, or development when there are no requirements for farm or service
customization.
What it does
The Farm Configuration Wizard performs the following tasks:
It configures selected service applications for your farm, such as Excel Calculation Services or the
Managed Metadata Service application.
It sets up managed accounts for those service applications, allowing SharePoint to manage account
passwords directly without administrator intervention.
It creates your farms first content web application.
What it does not do

The Farm Configuration Wizard does not perform the following tasks:
It does not perform fine-grained configurations; the service applications and web application created
by the Farm Configuration Wizard still require additional administration and configuration before
they are fully functional.
It does not allow you to specify different service accounts for certain service applications.
It does not do what the SharePoint 2013 Products and Technologies Configuration Wizard does. The
Farm Configuration Wizard configures components and services in the farm, whereas the SharePoint
2013 Products and Technologies Configuration Wizard is responsible for creating and updating the
farm itself.
To run the Farm Configuration Wizard:

1.
Open Central Administration, and then click Configuration Wizards.
2.
Under Farm Configuration, click Launch the Farm Configuration Wizard.
3.
On the Help Make SharePoint Better page, click one of the following options, and then click OK:
o
Yes, I am willing to participate. (Recommended)
No, I dont want to participate.
4.
On the Welcome page, next to Yes, walk me through the configuration of my farm using this
wizard, click Start the Wizard.
5.
On the Services page, in the Service Accounts section, click the service account option that you
want to use to configure your services.
Best Practice: The account that is used to perform the SharePoint installation should be
different from the one that is used to configure your service applications in the Farm
Configuration Wizard. For example, you may decide to use an account specifically created for the
SharePoint Application Service for this part of the process.
6.
In the Services section, review the list of services that will be used in your farm, clear the check boxes
for any services you do not want the Farm Configuration Wizard to create, and then click Next.
The farm service applications are created and started. This can take several minutes. Optionally, you can
open SQL Server Management Studio to follow the progress of the service application database creation.
Best Practice: Run some service applications under their own service account, such as Excel
Services or the User Profile Service Application. In this case, you need to clear the check boxes for
those services in the Farm Configuration Wizard, and create and configure specific service
accounts for these service applications by using Central Administration or Windows PowerShell.
7.
After the configuration completes, the Create Site Collection page opens in the wizard.
8.
In the Title and Description section, in the Title box, type the name of your new site.
9.
Optionally, in the Description box, type a description of what the site contains.
10. In the Web Site Address section, select a URL path for the site.
11. In the Template Selection section, in the Select a template list, select the template that you want to
use for the top-level site in the site collection, for example Team Site, and then click OK.
12. You will then see the Sorry to keep you waiting message and after the process completes, on the
This completes the Farm Configuration Wizard page, click Finish.
Performing manual farm configuration
The main advantage of performing manual confirmation of your farm instead of using the wizard is to
have a greater degree of control. Sometimes you may want to use a combination of the two approaches.
For example, if there were some service applications that you deselected when using the Farm
Configuration Wizard, you could manually configure those service applications to use a specifically
created service account afterward by using Central Administration or Windows PowerShell cmdlets.
Best Practice: In most production environments, business requirements lead to farm
topology designs and configuration that is not the same as the SharePoint out-of-box defaults.
Therefore, it is generally recommended to configure the farm manually in a production
environment.
Lab A: Deploying and Configuring SharePoint Server 2013

Part One
Scenario
The IT team at Contoso has created a server farm for an initial deployment of SharePoint Server 2013. The
server farm consists of four servers: a domain controller, a SQL Server 2012 deployment, an Office Web
Apps 2013 server, and a SharePoint 2013 server. Your team has configured the domain and installed SQL
Server 2012, SharePoint Server 2013, and Office Web Apps Server 2013. However, the team has not
configured any of these products. Your role is to provision the SharePoint 2013 server farm and perform
some farm-level configuration tasks. To start with, you will need to perform some pre-configuration tasks,
such as configuring an alias for the database server and creating a server farm account that SharePoint
will use to connect to the database server. You will then use the SharePoint Products Configuration
Wizard to provision the SharePoint farm.
Objectives
Provision a SharePoint 2013 server farm.
Lab Setup
Virtual machines: 20331B-NYC-DC-05, 20331B-NYC-DB-05, 20331B-NYC-SP-05, 20331B-NYC-OWA05
User name: [email protected]
Password: Pa$$w0rd
In this lab, you will perform the initial configuration of a SharePoint 2013 farm. You will create user
accounts for the farm, and create SQL Server aliases. These aliases can help with disaster recovery,
enabling you to redirect SQL Server requests to a new server without changes to the SharePoint
configuration.
Finally, you will run the SharePoint Products Configuration Wizard to configure the farm. This will create
the initial databases and create the Central Administration website.
Exercise 1: Provisioning a SharePoint 2013 Server Farm

Scenario
In this exercise, you will provision a SharePoint 2013 server farm. The server farm includes four servers, a
domain controller, a database server, a web server and an Office Web Apps server. In this exercise, you will
perform basic configuration. You will not configure Office Web Apps Server integration in this exercise.
You will create farm accounts on the domain controller, and you will create SQL Server aliases. You will
then use the SharePoint Products Configuration Wizard to complete the initial SharePoint configuration.
1. Create a Server Farm Account in Active Directory
2. Enable TCP/IP Connectivity in SQL Server
3. Create a SQL Server Alias on the SharePoint 2013 Server
4. Run the SharePoint Products Configuration Wizard
Task 1: Create a Server Farm Account in Active Directory
Start the 20331B-NYC-DC-05 virtual machine. Wait for the virtual machine to display the logon
screen, and then wait for a further five minutes before you proceed to the next step.
Start the 20331B-NYC-DB-05 virtual machine. Wait for the virtual machine to display the logon
screen before you continue.
Start the 20331B-NYC-SP-05 virtual machine. Wait for the virtual machine to display the logon screen
before you continue.
Start the 20331B-NYC-OWA-05 virtual machine. Wait for the virtual machine to display the logon
Log on to the 20331B-NYC-DC-05 virtual machine as CONTOSO\Administrator with the password

Pa$$w0rd.
Start Active Directory Administrative Center.
Create a new user with the following details.

Full name
SharePoint Farm
UPN logon
[email protected]
SAM Account Name logon
contoso\SPFarm
Password
Pa$$w0rd
Password never expires
Selected
User cannot change password
Selected
Task 2: Enable TCP/IP Connectivity in SQL Server
Log on to the 20331B-NYC-DB-05 virtual machine as CONTOSO\Administrator with the password

Pa$$w0rd.
Open SQL Server Configuration Manager.
Enable TCP/IP for the MSSQLSERVER server instance.
Restart the MSSQLSERVER server instance.
Task 3: Create a SQL Server Alias on the SharePoint 2013 Server
Log on to the 20331B-NYC-SP-05 virtual machine as CONTOSO\Administrator with the password

Pa$$w0rd.
Open the cliconfg.exe application from the C:\Windows\System32 folder.
Add a new server alias named ContosoDB, which uses the TCP/IP network library and connects to
the 20331B-NYC-DB-05 server.
Save the alias and close the SQL Server Client Network Utility.
Open the cliconfg.exe application from the C:\Windows\SysWOW64 folder.
Add a new server alias named ContosoDB, which uses the TCP/IP network library and connects to
the NYC-DB1 server.
Save the alias and close the SQL Server Client Network Utility.
Task 4: Run the SharePoint Products Configuration Wizard
On the 20331B-NYC-SP-05 virtual machine, run the SharePoint Products Configuration Wizard and
specify the following configuration settings.
Server farm
New server farm
Database server
ContosoDB
Database Name
SharePoint_Config
Database access account username
CONTOSO\SPFarm
Database access account password
Pa$$w0rd
Farm passphrase
Pa$$w0rd
Central Administration web application port number
50000
Central Administration web application authentication provider
NTLM
Verify that you can access the Central Administration website, but do not complete the Farm
Configuration Wizard (select the option to configure everything yourself).
Lesson 2
Scripting Installation and Configuration
5-19
An organization can reduce the time required to deploy a SharePoint server by scripting the installation
steps. Scripting also ensures that configuration is applied consistently, which reduces the chance for errors
and failure. Scripting is also required to automate the provisioning of SharePoint 2013.
In this lesson, you will learn how to perform a scripted installation and configuration of SharePoint 2013.
You will also learn how to slipstream cumulative updates and service packs for SharePoint 2013.
Lesson Objectives
After completing this lesson you will be able to:
Perform a scripted installation of SharePoint 2013.
Perform a scripted configuration of SharePoint 2013.
Understand and implement patch slipstreaming for SharePoint 2013.
Performing a Scripted Installation of SharePoint 2013

You can script the installation of SharePoint
binaries by specifying installation parameters in an
Extensible Markup Language (XML) file. The
default name attributed to such a file is
Config.xml. Microsoft provides sample Config.xml
files in the SharePoint distribution. You can simply
modify these files to match your environment. In
most cases, you need only to remove the
comment tags () and enter a valid
product ID.
For example, the following Config.xml file installs a
SharePoint server using the Server Farm
installation option and the Complete server type.
<Configuration>
<Package Id="sts">
<Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes"/>
</Package>
<Package Id="spswfe">
<Setting Id="SETUPCALLED" Value="1"/>
</Package>
<Logging Type="verbose" Path="%temp%" Template="SharePoint Server Setup(*).log"/>
<PIDKEY Value="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" />
<Display Level="none" CompletionNotice="no" />
<Setting Id="SERVERROLE" Value="APPLICATION"/>
<Setting Id="USINGUIINSTALLMODE" Value="0"/>
<Setting Id="SETUP_REBOOT" Value="Never" />
<Setting Id="SETUPTYPE" Value="CLEAN_INSTALL"/>
</Configuration>
The following sample Config.xml files are available in the Files folder in the SharePoint distribution.
Configuration File
Description
Setup\Config.xml
Stand-alone server installation using Microsoft SQL

Server 2008 R2 Express Edition
SetupFarm\Config.xml
Server farm installation
SetupFarmSilent\Config.xml
Server farm installation in silent mode
SetupFarmUpgrade\Config.xml
In-place upgrade of an existing farm
SetupSilent\Config.xml
Stand-alone server installation using SQL Server 2008

R2 Express Edition in silent mode
SetupSingleUpgrade\Config.xml
In-place upgrade of an existing single-server

installation
Performing a Scripted Configuration of SharePoint 2013

You can use Windows PowerShell cmdlets to
perform a scripted configuration of your
SharePoint 2013 farm. These cmdlets can also be
used in a Windows PowerShell script to provide an
automated farm configuration process.
The cmdlets you use to configure your farm
depend on whether you are installing on a standalone server, the first server in a farm, or on an
additional server in a multi-server farm.
Configure SharePoint Server 2013 on a

single server
In stand-alone server deployments, you use the New-SharePointFarm Windows PowerShell cmdlet to
configure the farm. This process is also used to create the first server in a multi-server farm.
Perform the following steps to configure SharePoint Server 2013 on a stand-alone server:
1.
Log on by using the Setup user account.
2.
On the Start screen, type sharepoint, and then click SharePoint 2013 Management Shell.
3.
At the Windows PowerShell command prompt, type the following command:

New-SharePointFarm -DatabaseServer <String> -DatabaseAccessAccount <PSCredential> FarmName <string>
Where:
o
<String> is the name of the database server, for example, SQLSRV01.
<PSCredential> is the DOMAIN\password of the user account that is performing the installation,
which is obtained by using the (Get-Credential DOMAIN\username) command.
<String> is the name of the farm, for example, MYFARM.
Configure SharePoint 2013 in a farm
In a SharePoint 2013 farm environment, you can add a server to an existing farm by using the ConnectSPConfigurationDatabase Windows PowerShell cmdlet.
Perform the following steps to add a new SharePoint 2013 server to the farm by using Windows
PowerShell:
1.
Verify that you are using an account that has the following memberships:
o
securityadmin fixed server role on the SQL Server instance
db_owner fixed database role on all databases that are to be updated
Administrators group on the server on which you are running the Windows PowerShell cmdlets
2.
3.
At the Windows PowerShell command prompt, type the following command to connect the server to
a configuration database:
Connect-SPConfigurationDatabase -DatabaseServer "<$DatabaseServer>" -DatabaseName
"<$RunSettings.ConfigurationDatabaseName>" -Passphrase "<$Passphrase>"
Where:
4.
<$DatabaseServer> is the name of the server that hosts the configuration database.
<$RunSettings.ConfigurationDatabaseName> is the name of the configuration database.
<$Passphrase> is the passphrase for the farm.
At the Windows PowerShell command prompt, type the following command to install the Help File
Collections:
Install-SPHelpCollection -All
5.
At the Windows PowerShell command prompt, type the following command to install the Security
Resource for SharePoint 2013:
Initialize-SPResourceSecurity
6.
At the Windows PowerShell command prompt, type the following command to install the basic
services:
Install-SPService
7.
At the Windows PowerShell command prompt, type the following command to install all the features:
Install-SPFeature -AllExistingFeatures
8.
At the Windows PowerShell command prompt, type the following command to install application
content:
Install-SPApplicationContent
9.
At the Windows PowerShell command prompt, type the following command to get a list of servers in
the farm:
Get-SPFarm | select Servers
Patch Slipstreaming
Like most other server products, SharePoint 2013
needs to be patched occasionally to keep it up-todate and bug-free. It can be a relatively complex
process to keep these servers products up to date,
but Microsoft provides a slipstreaming capability,
which can save you a lot of time and
administrative effort when installing SharePoint for
the first time. Slipstreaming is the process of
adding cumulative updates, or patches, and
service packs to the installation of a product, such
as SharePoint 2013.
When you slipstream an update or service pack,

you do not need to perform any other steps; the product installation process installs them for you as an
integral part of its installation routine. For example, when you install SharePoint 2013, it is automatically
patched up to the latest service pack and cumulative update level. If you did not slipstream your
installation, you would be required to run the normal installation routine, then install the latest service
pack, and then install the latest cumulative update. You can slipstream both service packs and cumulative
updates at the same time, as long as you do them in the correct release order.
The slipstreaming process

Perform the following steps to slipstream SharePoint 2013:
1.
Create an Installers folder on your local drive.
2.
Download the latest cumulative update and service pack executable files into the Installers folder.
3.
Create a subdirectory in the Installers folder named, for example, SP2013.
4.
Extract or copy your SharePoint 2013 installation files into the SP2013 folder.
5.
In the SP2013\Updates folder, open the Readme file. Note that this file informs you that any patches
placed in this folder will be applied during the initial install process.
6.
Close the Readme file.
7.
Open a command prompt and extract the service pack executable into the SP2013\Updates folder.
Example:
servicepack.exe /extract: .\SP2013\Updates
Where servicepack.exe is the name of the service pack executable.
8.
In the service pack dialog box, click Continue to accept the license terms.
9.
Click OK when installation is complete.
10. The SP2013\Updates folder will now have a lot more files in it, including one XML file and one MSP
file for each patch.
11. At the command prompt, extract the latest cumulative update into the SP2013\Updates folder.
Example:
cumulativeupdate.exe /extract: .\SP2013\Updates
Where cumulativeupdate.exe is the name of the latest cumulative update executable.
12. In the hotfix dialog box, click Continue to accept the license terms.
13. Click OK when installation is complete.
14. The slipstreaming process is now complete, and your next steps would be to install the
SharePoint 2013 prerequisites and then install SharePoint 2013 by running Setup.exe from the
SP2013 folder. During the installation, you will notice that the installer will spend a lot more time than
usual on the Applying Updates section.
Verifying installed updates
Perform the following steps to verify that your updates have installed correctly:
1.
On the Start screen, type sharepoint, and then click SharePoint 2013 Central Administration.
2.
In Central Administration, in the Upgrade and Migration section, click Check product and patch
installation status.
3.
This lists all the product components that make up SharePoint 2013 and any applied patches, with
their version numbers.
Note: An installed hotfix patch also provides a link to the patch; this is useful so that you
know exactly where to go to obtain updates for other servers you may add to your farm in the
future.
Slipstreaming language packs and Office Web Apps
Language packs themselves cannot be slipstreamed into the SharePoint installation, but you can
slipstream a language packs patches into its own installation process. Similarly, you cannot slipstream
Office Web Apps into the SharePoint installation, but you can slipstream Office Web Apps patches into
the Office Web Apps installation.
Lesson 3
Configuring SharePoint Server 2013 Farm Settings
After you install SharePoint 2013, you must configure several additional settings to enable key features in
your farm.
In this lesson, you will learn how to configure many of these farm settings in SharePoint 2013.
Lesson Objectives
Configure incoming and outgoing email settings for SharePoint 2013.
Configure mobile accounts for SharePoint 2013.
Configure workflow management for SharePoint 2013.
Understand and configure Office Web Apps integration with SharePoint 2013.
Configuring Incoming Email

Considering the importance of an email
messaging system in most organizations, one of
the first things you should do after installing
SharePoint 2013 is to configure your farm to allow
incoming and outgoing email. When you enable
incoming mail on your SharePoint sites, they can
begin to receive email messages and also receive
attachments in libraries and lists.
Install the SMTP service

The first step toward configuring incoming email is
to install the SMTP service feature on your
SharePoint 2103 server. You install the SMTP
service by using the Add Roles and Features tool in Server Manager.
You can use the SMTP service in two different ways:
Install the SMTP service on all the WFE servers that you want to configure incoming mail for.
If the SMTP service runs on a server that is not part of your SharePoint server farm, you can create an
email drop folder on that server and specify this as the network location from which SharePoint
should retrieve incoming email.
Perform the following steps to install the SMTP service:

1.
On the Start screen, click Server Manager.
2.
In Server Manager, click Add roles and features.
3.
In the Add Roles and Features Wizard, on the Before you begin page, click Next.
4.
On the Select installation type page, ensure that Role-based or feature-based installation is
selected, and then click Next.
5.
On the Select destination server page, ensure your SharePoint 2013 server is selected in the server
pool, and then click Next.
6.
On the Select server roles page, click Next.
7.
On the Select features page, select SMTP Server.
8.
In the Add Roles and Features Wizard dialog box, click Add Features, and then click Next.
9.
On the Confirm installation selections page, click Install.
10. On the Installation progress page, ensure that the installation finished successfully, and then click
Close.
Configure the SMTP service
After installing the SMTP Server feature, you need to configure it to allow incoming email from the
domains mail server. When configuring the SMTP Server properties, you can choose to accept relayed
email from all servers apart from those that you explicitly exclude, or you can choose to only accept
relayed email from servers that you explicitly include. When adding servers to the exclusion or inclusion
list, you can either add servers individually by IP address, or you can specify them in groups by domain or
subnet.
Perform the following steps to configure the SMTP service:
1.
On the Start screen, click Internet Information Services (IIS) 6.0 Manager.
2.
In IIS Manager, expand the server name that contains the SMTP server that you want to configure.
3.
If the service has not started, right-click the SMTP virtual server that you want to configure, and then
click Start.
4.
Right-click the SMTP virtual server that you want to configure, and then click Properties.
5.
On the Access tab, in the Access control area, click Authentication.
6.
In the Authentication dialog box, verify that Anonymous access is selected.
7.
Click OK.
8.
On the Access tab, in the Relay restrictions area, click Relay.
9.
To enable relaying from any server, click All except the list below.
To accept relaying from one or more specific servers, follow these steps:
i.
Click Only the list below.
ii.
Click Add, and then add servers one at a time by IP address, or in groups by using a subnet
or domain.
iii.
Click OK to close the Computer dialog box.
Click OK to close the Relay Restrictions dialog box.
10. Click OK to close the Properties dialog box.

After you configure the service, you need to set it to start automatically.
Perform the following steps to set the SMTP service to start automatically:
1.
On the Start screen, type services, and then click Services.
2.
In Services, right-click Simple Mail Transfer Protocol (SMTP), and then click Properties.
3.
In the Simple Mail Transfer Protocol (SMTP) Properties dialog box, on the General tab, in the
Startup type list, select Automatic.
4.
Click OK.
There are two distinct scenarios for incoming mail; basic and advanced, and these are exposed in the
SharePoint 2013 administration settings:
A basic scenario defines a farm that contains only a single server, and this is the recommended
approach for organizations that do not have any custom requirements and are happy to use the outof-the-box settings.
An advanced scenario defines a farm containing one, or more commonly, multiple servers that
require a more specific set of configuration settings.
Configure incoming email in a basic scenario

Perform the following steps to configure incoming email in a basic scenario:
1.
On the Start screen, right-click, and then in the AppBar, click All apps.
2.
On the Apps screen, scroll across, and then click SharePoint 2103 Central Administration.
3.
In Central Administration, click System Settings.
4.
On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure
incoming e-mail settings.
5.
If you want to enable sites on this server to receive email, on the Incoming E-Mail Settings page, in
the Enable Incoming E-Mail section, click Yes.
6.
Select the Automatic settings mode.
7.
In the Incoming E-Mail Server Display Address section, in the E-mail server display address box,
type a display name for the email server, for example, mail.fabrikam.com.
8.
Use the default settings for all other sections, and then click OK.
Configure incoming email in an advanced scenario

You must perform several additional preparation steps before you can configure incoming email in an
advanced scenario. These extra steps depend on your needs and environment, including whether you:
Use a Directory Management Service.
Have an Exchange Server in your environment.
Prefer to use an external email drop folder.
The steps to configure incoming email in an advanced scenario are also more complex than the basic
scenario.
Additional Reading: The steps to configure email in an advanced scenario are beyond the
scope of this course. For more information, see Configure incoming email in an advanced scenario
and Prepare your environment for incoming email in an advanced scenario at
Configuring Outgoing Email

Configure outgoing email for a farm
To configure outgoing email settings for a farm,
use the Central Administration site. After the
outgoing email settings are configured, your users
can receive email notifications about changes to
site collections, and administrators can receive
email notifications about user access requests to
the site.
Perform the following steps to configure outgoing
email for a farm by using Central Administration:
5-27
1.
On the Start screen, right-click, and then in the AppBar, click All apps.
2.
On the Apps screen, scroll across, and then click SharePoint 2103 Central Administration.
3.
In Central Administration, click System Settings.
4.
outgoing e-mail settings.
5.
On the Outgoing E-Mail Settings page, in the Mail Settings section, in the Outbound SMTP
server box, type the SMTP server name for outgoing email (for example, mail.example.com).
6.
In the From address box, type the email address as you want it to be displayed to email recipients.
7.
In the Reply-to address box, type the email address to which you want email recipients to reply.
8.
In the Character set list, select the character set that is appropriate for your language.
9.
Click OK.
Configure outgoing email for a web application
You can also use the Central Administration site to configure outgoing email settings for a specific web
application rather than the whole farm.
Note: To configure outgoing email for a specific web application, first configure the default
outgoing email for all web applications in the farm. Then, when you configure the outgoing
email for a specific web application, that configuration will override the default farm-level
outgoing email settings.
Perform the following steps to configure outgoing email for a specific web application by using Central
Administration:
1.
In Central Administration, in the Application Management section, click Manage web applications.
2.
On the Web Applications Management page, select a web application, and then in the General
Settings group on the ribbon, click Outgoing E-mail.
3.
On the Web Application Outgoing E-Mail Settings page, in the Mail Settings section, in the
Outbound SMTP server box, type the name of the SMTP server for outgoing email (for example,
mail.fabrikam.com).
4.
In the From address box, type the email address (for example, the site administrator alias) as you
want it to be displayed to email recipients.
5.
In the Reply-to address box, type the email address (for example, a help desk alias) to which you
want email recipients to reply.
6.
In the Character set list, click the character set that is appropriate for your language.
7.
Click OK.
Configuring Mobile Accounts

SharePoint 2013 provides several new viewing
enhancements and features for different mobile
devices and platforms. These features are aimed at
improving user productivity and the end user
experience on mobile devices when they are away
from the office. You can configure and manage
mobile accounts in SharePoint 2013 to enable
your users to subscribe to SMS alert services that
are provided by mobile service providers. When
changes occur on SharePoint items and lists, these
SMS alerts are sent to your users mobile devices.
Mobile account overview
When configuring mobile accounts for SharePoint 2013, you can either configure one mobile account for
all the web applications in a farm or you can configure one mobile account for one specific web
application. However, you can only configure one mobile account in the farm, so it is one or the other;
not both.
If you choose to configure one mobile account for all web applications, all your users have the capability
to subscribe to SMS alerts. However, if you have an environment where your web applications are split by
department, you might want to allow only one department, for example your sales team, to subscribe to
SMS alerts. In this scenario, you would configure the mobile account purely for the sales team web
application.
Obtain a root certificate for your service provider
Before you configure a mobile account, You need to import the root certificate of your service provider's
HTTPS web address, and then create a trusted root authority before you configure a mobile account in
SharePoint 2013.
Note: This procedure can only be performed manually by using Windows PowerShell.
Perform the following steps to import a root certificate and create a trusted root authority by using
Windows PowerShell:
1.
2.
To get the root certificate, at the Windows PowerShell command prompt, type the following
command:
$cert = Get-PfxCertificate <ObtainedCertificatePath>
3.
To create a trusted root authority, at the Windows PowerShell command prompt, type the following
command:
New-SPTrustedRootAuthority -Name <Name> -Certificate $cert
Where:
o
<Name> is the name of the trusted root authority that you want to create.
<ObtainedCertificatePath> is the location of the root certificate file.
Configure a mobile account
You can use Central Administration or Windows PowerShell to configure a mobile account for a server
farm or for a specific web application.
Perform the following steps to configure a mobile account for a server farm by using Central
Administration:
1.
2.
On the Central Administration home page, click System Settings.
3.
mobile account.
4.
On the Mobile Account Settings page, in the Text Message (SMS) Service Settings section, click
the Microsoft Office Online link to access a list of service providers.
5.
On the service provider page, in the Choose your wireless service provider's country/region list,
select the country or region in which your wireless service provider is located.
6.
On the service provider page, in the Choose your current wireless service provider list, select the
wireless service provider that you want to use. After you make this selection, a list of potential service
providers are listed on the page. When you click one of these providers, you are redirected to the
website of the service provider that you selected. On the website, you apply for the SMS service.
When you receive the required information from the service provider, return to the Mobile Accounts
Settings page.
7.
In the The URL of Text Message (SMS) Service box, type the URL of the SMS service. Ensure that
the URL you enter is an HTTPS URL.
8.
In the User Name box and Password box, type the user name and password that you received from
the SMS service provider.
9.
To confirm that the URL and user credentials are correct, click Test Service.
10. Click OK.

Perform the following steps to configure a mobile account for a server farm by using Windows
PowerShell:
1.
2.

Set-SPMobileMessagingAccount -Identity sms -WebApplication <WebApplicationUrl> [ServiceUrl <ServiceUrl>] [-UserId <UserId>] [-Password <Password>]
Where:
o
<WebApplicationUrl> is the Central Administration URL.
<ServiceUrl> is the URL for the server where the SMS service is located.
<UserId> is the user name that you received from the SMS service provider.
<Password> is the user password that you received from the SMS service provider.
Example:
Set-SPMobileMessagingAccount -Identity sms -WebApplication http://myserver:8080 ServiceUrl https://www.example.com/omsservice.asmx -UserId [email protected] Password password1
Note: To configure a mobile account for a web application by using Windows PowerShell,
use the web application URL as the <WebApplicationUrl> instead of the Central Administration
URL.
Manage a mobile account
You can use Windows PowerShell to retrieve mobile account information for a server farm or for a web
application. This also enables you to verify that the Set-SPMobileMessagingAccount cmdlet worked
correctly.
Perform the following steps to retrieve mobile account information for a server farm by using Windows
PowerShell:
1.
2.

Get-SPMobileMessagingAccount -WebApplication <WebApplicationUrl>
Where <WebApplicationUrl> is the Central Administration URL.

Note: To retrieve mobile account information for a web application by using Windows
PowerShell, use the web application URL as the <WebApplicationUrl> instead of the Central
Administration URL.
You may need to delete a mobile account from your farm; for example, the organization decides that it
no longer needs to send out SMS alerts to its users. If you delete a mobile account for a server farm or for
a web application, the account will no longer be available, and users will no longer be able to subscribe to
SMS alerts. Deleting a mobile account does not delete the account that you set up with the service
provider.
Perform the following steps to delete a mobile account for a server farm:
1.
2.
On the Central Administration home page, click System Settings.
3.
On the System Settings page, in the E-mail and Text Messages (SMS) section, click Configure
mobile account.
4.
On the Mobile Account Settings page, clear entries from all the boxes, and then click OK.
Perform the following steps to delete a mobile account for a web application:
1.
On the Central Administration home page, in the Application Management section, click Manage
web applications.
2.
On the Web Applications Management page, select a web application, and then in the General
Settings group on the ribbon, click Mobile Account.
3.
5-31
On the Web Application Text Message (SMS) Service Settings page, delete entries from all the
boxes, and then click OK.
Note: There are no equivalent Windows PowerShell cmdlets for these procedures.
Configuring Workflow Management

When creating a new workflow for SharePoint
2013, there is a new option available in SharePoint
Designer 2013 called Platform Type. There are
three available platform types: SharePoint 2010
Workflow, SharePoint 2013 Workflow, and
SharePoint 2013 Workflow Project Server.
However, without performing additional
configuration steps in Workflow Manager, the
SharePoint Designer 2013 user interface lists
SharePoint 2010 Workflow as the only available
option.
Note: The SharePoint 2013 Workflow
Project Server option is only available when Project Server is installed and configured.
Platform Type
Platform Framework
Requirements
SharePoint 2010
Workflow
Windows Workflow
Foundation 3
This workflow is installed automatically with

SharePoint 2013.
SharePoint 2013
Workflow
Windows Workflow
Foundation 4
This workflow requires SharePoint 2013 and

Workflow Manager.
Workflow Manager must be downloaded
and installed separately; it does not get
installed automatically with SharePoint
2013.
SharePoint 2013
Workflow
Project Server
Windows Workflow
Foundation 4
This workflow requires SharePoint 2013,

Workflow Manager, and Project Server
2013.
Note: The SharePoint 2013 Workflow is not supported in SharePoint Foundation 2013.
Configure Workflow Manager to work with a SharePoint 2013 farm
You need to install and configure Workflow Manager before you can configure it to work with your
SharePoint 2013 server farm. After Workflow Manager is installed and configured, SharePoint 2013
Workflow and SharePoint 2013 Workflow Project Server will appear in the drop-down list for the
Platform Type field in the SharePoint Designer 2013 user interface.
To install and configure Workflow Manager, see Installing and Configuring Workflow at
When configuring Workflow Manager to work with your SharePoint 2013 farm, there are two main
aspects to consider:
Have you installed Workflow Manager on a server that is part of your SharePoint farm?
Will communications between Workflow Manager and SharePoint Server 2013 use the HTTP or
HTTPS protocol?
Perform the following steps to configure Workflow Manager on a SharePoint 2013 farm-based server that
will communicate over HTTPS:
1.
Determine whether you need to install Workflow Manager certificates in SharePoint, because under
some specific circumstances, you have to obtain and install Workflow Manager certificates first. To
verify this and for instructions on doing so, see Installing Workflow Manager certificates in SharePoint
Server 2013 at http://go.microsoft.com/fwlink/?Linkid=299559
2.
Log on to the computer in the SharePoint Server 2013 farm where you installed Workflow Manager.
3.
On the Start screen, type sharepoint, right-click SharePoint 2013 Management Shell, and then in
the AppBar, click Run as administrator.
4.
At the Windows PowerShell command prompt, run the Register-SPWorkflowService cmdlet.
Example:
Register-SPWorkflowService SPSite "https://myserver/mysitecollection"
WorkflowHostUri https://workflow.example.com:12290
Perform the following steps to validate the configuration:

1.
Add a user to your SharePoint site, and grant the user Site Designer permissions.
2.
Install SharePoint Designer 2013 and create a workflow based on the SharePoint 2013 Workflow
platform.
3.
Run this workflow from the SharePoint user interface.
Lab B: Deploying and Configuring SharePoint Server 2013

Part Two
Scenario
Now that you have provisioned a SharePoint server farm, you need to complete some core farm-level
configuration tasks. First, you will configure incoming and outgoing email for the new deployment. You
will then configure your farm to communicate with an Office Web Apps Server farm, to provide your users
with the ability to view and edit Microsoft Office documents in the browser window.
Objectives
After completing this lab, you should be able to:
Configure incoming email for a SharePoint 2013 deployment.
Configure outgoing email for a SharePoint 2013 deployment.
Configure Office Web Apps integration.
Lab Setup
Virtual machines: 20331B-NYC-DC-05, 20331B-NYC-DB-05, 20331B-NYC-SP-05, 20331B-NYC-OWA05
Password: Pa$$w0rd
In this lab, you will further configure a SharePoint farm. You will set up incoming and outgoing email, and
you will configure integration with Office Web Apps.
In the first exercise, you will configure incoming email. As part of this process, you will configure the SMTP
service on the SharePoint server. In your production environment, this may not be necessary, such as if
you are using a Microsoft Exchange Server. You will enable a list to receive email and then test incoming
email by sending an email message to the list and verifying that the emailed item appears in the list.
In the second exercise, you will configure outgoing email. Again, you will use the SMTP service that you
configured in the first exercise and you will view email messages sent by the server by using Notepad to
open the message files in a drop folder rather than by using an email client. This is unlikely to match your
production environment, but it is used in the lab environment for testing purposes.
Finally, in the third exercise, you will configure integration with Office Web Apps. You will create a new
Office Web Apps farm by using Windows PowerShell on the Office Web Apps server, and then you will
configure SharePoint to work with the Office Web Apps server. In the lab environment, you will configure
the two servers for communication over HTTP; in a production environment, you should use HTTPS
wherever possible. You will test the Office Web Apps configuration by viewing an Excel workbook in the
Excel Web App.
Exercise 1: Configuring Incoming Email

Scenario
In this exercise, you will configure incoming email for SharePoint. You will configure the SMTP service on
the SharePoint server, and then configure incoming email settings by using the Central Administration
website.
You will create a web application and site collection that you will use to test the changes that you have
made. You will then enable a list to receive email, and test the incoming email functionality by using a
Windows PowerShell script to send an email message to the email-enabled list. Finally, you will verify that
the contents of the email are added as an item in the list.
1. Enable the SMTP Server feature on the SharePoint Server
2. Configure the SMTP service
3. Create a DNS record for the email domain and SharePoint site
4. Configure incoming email settings in Central Administration
5. Create an email-enabled Announcement app
6. Test incoming email functionality
Task 1: Enable the SMTP Server feature on the SharePoint Server
Switch to the 20331B-NYC-SP-05 virtual machine. If you are not already logged on, log on as
CONTOSO\Administrator with the password Pa$$w0rd.
Install the SMTP Server feature, including any required roles and features, and the associated
management tools.
Task 2: Configure the SMTP service
Open Internet Information Services (IIS) 6.0 Manager
Enable anonymous access to the SMTP virtual server.
Restrict mail relaying to the web server.
Create a new domain, mail.contoso.com.
Set the SMTP service to start automatically.
Task 3: Create a DNS record for the email domain and SharePoint site
Switch to the 20331B-NYC-DC-05 virtual machine. If you are not already logged on, log on as
Open DNS Manager.
Add a new host record to the contoso.com forward lookup zone with the following properties.
Property
Setting
Name
mail
IP address
172.16.1.21
Property
Setting
Name
sharepoint
IP address
172.16.1.21
Task 4: Configure incoming email settings in Central Administration
Open the Central Administration website.
Navigate to the System Settings page.
Configure incoming email settings with the following properties.

Property
Setting
Enable incoming e-mail
Yes
Use SharePoint directory management to create distribution groups
No
Incoming e-mail server display address
mail.contoso.com
Task 5: Create an email-enabled Announcement app
Create a new web application with the following non-default properties.

Property
Setting
Host header
sharepoint.contoso.com
Create a new site collection with the following properties.

Property
Setting
Web application
http://sharepoint.contoso.com
Title
Configuration Test
URL
Site template
Team Site
Primary site collection administrator
CONTOSO\Administrator
In the registry, disable loopback checking for the sharepoint.contoso.com domain to enable you to
visit the site on the SharePoint server.
Restart Internet Information Services (IIS).
Using Internet Explorer, browse to http://sharepoint.contoso.com. Log on to the site with the user
name CONTOSO\Administrator and the password Pa$$w0rd.
Create a new announcements list named Email Announcements.
Navigate to the Settings page for the Email Announcements list.
Configure the Email Announcements list to receive email, with the email address
[email protected], sent from any sender.
Task 6: Test incoming email functionality
Use Windows PowerShell to run the SendEmail.ps1 script, which is in the E:\Mod05 folder on the
web server. This script sends an email to the Email Announcements list.
In Internet Explorer, view the Email Announcements list. Periodically refresh the list until a new
announcement is added to the list and then examine the contents of the new announcement. The
content of the announcement indicates that the item was added by email.
Note: SharePoint uses a timer job to process email messages. This timer job runs frequently, but you
may have a small delay while you wait for the timer job to complete.
Results: After completing this exercise, you should have configured incoming email for the SharePoint
server. You should have configured a list to receive incoming email and verified the configuration by
sending an email message to the announcements list. You should then have verified that the list contains
the new announcement emailed to the list.
Exercise 2: Configuring Outgoing Email

Scenario
In this exercise, you will configure SharePoint to send email. You will configure the outgoing email
settings by using the Central Administration website.
You will then test the outgoing email settings by using an alert on an announcements list. You will
subscribe to alerts for an existing list, and then add a new announcement to trigger an alert. You will
verify that the alert email was sent correctly by checking a drop folder and viewing the email source in
Notepad.
1. Configure outgoing email settings in Central Administration
2. Subscribe to an alert on the Email Announcements list
3. Create a new announcement
4. Verify that an email message was sent
Task 1: Configure outgoing email settings in Central Administration
On the 20331B-NYC-SP-05 virtual machine, if you are not already logged on, log on as
Navigate to the System Settings page.
Configure outgoing email settings with the following properties.

Property
Setting
Outbound SMTP server
172.16.1.21
From address
[email protected]
Reply-to address
[email protected]
Task 2: Subscribe to an alert on the Email Announcements list
Navigate to the http://sharepoint.contoso.com site, and then browse to the Email Announcements
list.
Create a new alert for the Email Announcements list. The alert should inform you about all changes,
when anything changes, and it should be sent immediately.
Task 3: Create a new announcement
Create a new announcement in the Email Announcements list with the following properties.
Property
Setting
Title
New Announcement
Body
This is a new announcement
Task 4: Verify that an email message was sent
In File Explorer, browse to the C:\inetpub\mailroot\Drop folder. The folder should contain two
Microsoft Email Message (.eml) files.
Open the most recent .eml file by using Notepad. Verify that the email contains the content from the
new announcement.
Note: The .eml files contain complete email messages, including header information. You can find
the content of the message toward the end of the file. The alert is formatted as HTML. If you search the
file for Title: or Body:, you should be able to locate the announcement content.
Results: After completing this exercise, you should have configured SharePoint to send outgoing email.
You should have tested that outgoing email is working correctly by using an alert on an announcements
list.
Exercise 3: Configuring Integration with Office Web Apps Server 2013

Scenario
In this exercise, you will configure integration between Office Web Apps Server and SharePoint Server.
You will provision a new Office Web Apps server farm, which you will configure to enable communication
over HTTP.
You will then configure SharePoint to connect to the new Office Web Apps server farm. Like Office Web
Apps, you will configure SharePoint to connect by using HTTP. To ensure requests are authenticated
correctly, you will also configure SharePoint to allow OAuth tokens to be passed over HTTP.
Finally, you will test the Office Web Apps and SharePoint integration by creating a new document in a
document library and viewing that document in Office Web Apps.
1. Provision a new Office Web Apps server farm
2. Configure the SharePoint server farm to use the Office Web Apps server farm
3. Verify that Office Web Apps integration is configured correctly
Task 1: Provision a new Office Web Apps server farm
Log on to the 20331B-NYC-OWA-05 virtual machine as CONTOSO\Administrator with the password

Pa$$w0rd.
Open a new Windows PowerShell scripting window.
Use the New-OfficeWebAppsFarm cmdlet to provision a new Office Web Apps farm with the
following properties.
Property
Setting
Internal URL
http://NYC-OWA1
Allow HTTP
True
Editing enabled
True
In Internet Explorer, browse to the discovery service at http://NYC-OWA1/hosting/discovery to

verify that the Office Web Apps farm is configured correctly.
Task 2: Configure the SharePoint server farm to use the Office Web Apps server farm
Open a SharePoint 2013 Management Shell scripting window.
Use the New-SPWOPIBinding cmdlet to create a binding between the SharePoint server and the
Office Web Apps server with the following properties.
Property
Setting
Server name
NYC-OWA1
AllowHTTP
True
Use the Set-SPWOPIZone cmdlet to indicate that the SharePoint server farm should communicate
with the Office Web Apps server farm by using the internal-http zone.
Use the Get-SPSecurityTokenServiceConfig cmdlet to retrieve a reference to the SharePoint

security token service configuration and then set the AllowOAuthOverHttp property of that object
to true.
Task 3: Verify that Office Web Apps integration is configured correctly
Using Internet Explorer, navigate to http://sharepoint.contoso.com, and then browse to the

Documents document library.
Create a new Excel workbook named OWA Integration Test.xlsx, and verify that it opens in the
Microsoft Excel Web App.
Results: After completing this exercise, you should have configured integration between Office Web Apps
Server 2013 and SharePoint 2013. You should have tested this integration by creating a new Excel
workbook and viewing the workbook in the Excel Web App.

In this module, you have learned how to install and configure SharePoint 2013, both by using the
installation wizards, and by scripting installation.
Review Question(s)
Test Your Knowledge
Question
When choosing a single server deployment with built-in database which of the
following statements is true?
SharePoint will use SQL Server 2008 R2 as the database engine, which does not
have any size restrictions.
SharePoint will use SQL Server 2008 R2 Express as the database engine, which has a
maximum database size limit of 10 GB.
SharePoint will use SQL Server 2012 as the database engine, which does not have
any size restrictions.
SharePoint will use SQL Server 2012 Express as the database engine, which has a
maximum database size limit of 15 GB.
SharePoint will use localdb as the database engine, which does not have any size
restrictions.
Test Your Knowledge
Question
Which of the following workflow types is installed automatically with SharePoint 2013?
SharePoint Portal Server 2003 Workflow
Office SharePoint Server 2007 Workflow
SharePoint 2010 Workflow
SharePoint 2013 Workflow
SharePoint 2013 Workflow Project Server
Test Your Knowledge

Question
Microsoft provides sample Config.xml files that you can use to perform a scripted
installation of SharePoint 2013. You must make some changes to these files before you
can use them to install SharePoint. Which of the following options describes the
minimum required changes to one of the sample Config.xml files before you can use it
to install SharePoint?
Enter the root domain.
Remove the comment tags.
Enter a valid product key.
Remove the comment tags and enter a valid product key.
Remove the comment tags, enter a valid product key, and enter the root domain.

6-1
Module 6
Creating Web Applications and Site Collections
Contents:
Module Overview
6-1
Lesson 1: Creating Web Applications
6-2
Lesson 2: Configuring Web Applications
6-12
6-24
Lesson 3: Creating and Configuring Site Collections
6-29
6-38
6-43
Module Overview
After installing your Microsoft SharePoint Server 2013 farm, you are ready to begin deploying sites and
content, such as an organizational intranet site.
In this module, you will learn about the key concepts and skills related to the logical architecture of
SharePoint including web applications, site collections, sites, and content databases. Specifically, you will
learn how to create and configure web applications and to create and configure site collections.
Objectives
After completing this module you will be able to perform the following tasks in SharePoint 2013:
Create web applications.
Configure web applications.
Create site collections.
Configure site collections.
Lesson 1
Creating Web Applications

This lesson examines core web application infrastructure concepts, including how to create web
applications in your SharePoint 2013 environment. You will also learn about key web application
components, such as web application authentication providers, content databases, service application
connections, and web application zones.
Lesson Objectives
Understand core web application infrastructure concepts.
Understand the concepts of authentication providers and service application connections.
Create web applications.
Understand and use web application zones.
Understanding Web Applications in SharePoint 2013

Before discussing web applications in SharePoint
2013, it is important to know where they sit in the
overall logical structure of a SharePoint 2013
environment.
6-2
Overview of the SharePoint logical structure
6-3
A typical SharePoint environment is made up of several components and follows a distinct structure. The
following diagram shows the basic logical structure of a SharePoint environment.
FIGURE 6.1:SHAREPOINT LOGICAL STRUCTURE

The following components make up a typical SharePoint environment:
A web application is the highest level component of the logical structure within a farm. A farm can
have one or more web applications.
Within a web application are one or more site collections. Site collections have a Uniform Resource
Locator (URL) that is a managed path.
A site collection contains one or more sites. When you create a site collection, you also create the
top-level site in that site collection. Below that top-level site can be one or more additional sites,
usually referred to as subsites.
A site typically contains pages, lists, and libraries.
Lists and libraries contain items and documents that can also be contained in folders.
A site collection and all of its content is hosted in a content database. There can be one or more
content databases associated with a web application.
SharePoint 2013 web applications
A web application in SharePoint 2013 is a Microsoft Internet Information Services (IIS) website that acts as
a logical unit for all the site collections that you create. Therefore, you need to create a web application
before you can create any site collections. When you create a web application, it is represented by an IIS
website and SharePoint configuration data and is associated with its own or a shared application pool.
Web application characteristics

Web applications have the following characteristics:
You use web applications to isolate content, processes, features, and users.
You can separate content that is accessible by anonymous users from content that is accessed by
authenticated users, or content that is accessible by partners from content that is accessible by
employees, by hosting the content in separate web applications.
6-4
Each web application has a unique domain name, which helps to prevent cross-site scripting attacks.
You can assign a unique application pool to a web application, which isolates its processes.
When you create a new web application, you also create a new content database that defines the
authentication method used by the application pool to connect to the database.
When you create a new web application, you specify the authentication method used to connect to
the IIS website.
SharePoint Server 2013 provides a set of service applications that are available for each web
application. You can select which service applications you want to use for each web application that
you create by associating the web application with a proxy group or by specifying a custom set of
service applications for the web application.
Policies can be specified uniquely for each web application.
Web applications and content databases
A site collection and all of its content, including documents and files in document libraries, list items, and
Web Part properties, is hosted in a back-end content database. There can be one or more content
databases associated with a web application. The content from all sites in a site collection is stored in the
content database. A site collection cannot span more than one content database. The only way to store
sites in separate content databases is to put sites in separate site collections.
Because of this relationship between content databases and storage management, governance and
service level agreements (SLAs) often drive an organization to create multiple site collections so that site
collections can be distributed across content databases.
Web applications and IIS websites
Before you create and configure web applications and site collections, it is important that you understand
the underlying component of a SharePoint web application, which is an IIS website.
Internet Information Services (IIS)
Internet Information Services (IIS) is a web server and extensibility module set from Microsoft. SharePoint
2013 sits on top of IIS and relies on it to process its requests. IIS has several features that help you to
manage your SharePoint environment and boost its performance, reliability, and security. The top-level
logical component within a SharePoint farm is the web application, and a web application in SharePoint
corresponds to a website in IIS.
When browsing and accessing websites on an IIS web server, you need to provide destination address
information to access the network resources. These are made up of three main components: the IP
address, the port number, and the host header.
IP address
Each computer on an Internet Protocol (IP) network needs a unique identifier, so that it can be easily and
uniquely identified. Computers on an IP network such as the Internet or an intranet use the TCP/IP
protocol to communicate with other computers on the network, and the unique identifier they use is an IP
address.
An IP address is a numerical marker assigned to each computer, or sometimes other network devices such
as printers, on an IP network. The IP address provides two key functions: host identification and location
addressing, where the host defines what is being looked for and the address defines where it is located.
Port number
A port is an application or service-specific software component that acts as an endpoint for

communications between computers on a network. The port number, when associated with a computers
IP address, forms the destination address for communications between a source and destination
computer.
6-5
Ports are used to uniquely identify various applications and services running on a computer for protocols
such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), which are common
transport layer protocols. The IP address and port number combination must be globally unique; however,
different protocols or IP addresses can use the same port number for communications.
Host header
A host header is another piece of address information that you can use as well as the IP address and port
number to uniquely identify a web domain or application server. Host headers refer to the portion of the
HTTP protocol address that tells the web server the Domain Name System (DNS) name of the site that the
client is connecting to. You can apply host headers at two different levels in SharePoint Server 2013:
The web application (IIS website) level
The site collection level
It's important to understand the distinction between these two levels. Host headers at the IIS website level
are only intended for path-based site collections. Host headers at the site collection level are only
intended for host-named site collections. In most cases, applying a host header binding at the IIS website
level makes it impossible to access host-named site collections through the IIS website. This is because IIS
will not respond to requests for host names that differ from the host header binding.
Logical Infrastructure for Web Applications

When you create a new web application, you also
create a new content database and define the
authentication method used to connect to the
database. One web application can support
multiple authentication providers.
Web applications and authentication

SharePoint 2013 supports a variety of
authentication methods and authentication
providers for the following authentication types:
Windows authentication. This authentication

method uses your existing Windows
authentication provider, Active Directory Domain Services (AD DS) and Windows domain
authentication protocols to validate the credentials of connecting users. Windows authentication
methods, which are used by both claims-based authentication and classic mode, include NTLM,
Kerberos, Digest, and Basic.
Forms-based authentication. This authentication method is a claims-based system based on ASP.NET

membership and role provider authentication. Forms-based authentication is used against credentials
stored by an authentication provider, such as AD DS, a SQL Server database, or a Lightweight
Directory Access Protocol (LDAP) data store.
Security Assertion Markup Language (SAML) token-based authentication. This authentication method,
also referred to as claims token-based authentication, coordinates with administrators of a claimsbased environment, such as your own internal Active Directory Federation Services (AD FS) 2.0 service,
which is a SAML token-based authentication environment. SAML token-based authentication
environments include an identity provider security token service (IP-STS). The IP-STS issues SAML
tokens on behalf of users whose accounts are included in the associated authentication provider.
Tokens can include claims about a user, such as the user name and the groups to which the user
belongs.
User authentication
6-6
User authentication verifies a users identity through an authentication provider. Typically, this is a
directory database, such as Active Directory, containing user name and password credentials. This level of
authentication happens when a user tries to access a SharePoint resource, such as a website or document,
in a document library.
There are two distinct methods of user authentication: classic-mode and claims-based.
Classic-mode authentication
This authentication mechanism is sometimes referred to as Windows classic mode authentication, because
it only uses Windows authentication. Classic-mode authentication is based on a Windows security token
generated by NTLM or Kerberos.
Classic-mode authentication has been deprecated in SharePoint 2013, but it is still a supported
authentication type. Classic-mode authentication is only configurable through Windows PowerShell
cmdlets; there is no user interface for it in the Central Administration website.
Claims-based authentication
This is the default authentication mechanism in SharePoint 2013. It is built on claims-based security
tokens that are generated by the Security Token Service (STS) in SharePoint. These tokens contain claims
that define what a user is; in other words, the claims define the role and/or group memberships for each
user. The tokens do not define what a user can do; it is the responsibility of the application to define what
a user can do, based on the claims that the user presents.
Best Practice: Claims-based authentication is the default authentication mechanism, and it
is recommended that you use claims-based authentication for user authentication in SharePoint
2013.
Claims-based authentication improvements

There have been several improvements to the claims-based authentication mechanism in SharePoint
2013:
Simpler classic-mode to claims-based authentication migration through use of the new ConvertSPWebApplication Windows PowerShell cmdlet.
Additional Reading: For more information, see Migrate from classic-mode to claims-based
authentication in SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299604
Caching of login tokens by the new Distributed Cache Service removes the need to configure load
balancing affinity, and improves memory utilization on web servers.
More detailed and categorized logging improves the troubleshooting of authentication problems.
Additional Reading: For more information, see Plan for user authentication methods in
Web applications and service applications
6-7
A web application is associated with a service application through a service application connection, also
known as an application proxy. Service application connections are added to a group of service
application connections, also known as an application proxy group. When you create a web application,
one of the configuration steps you perform is to choose a service application connection group, or proxy
group, to connect to the web application. A web application can be connected to the default proxy
group, which is what occurs by default, or you can select a custom proxy group; however, you can only
create one custom proxy group for each web application in the farm.
Note: Most deployments use a single proxy group, whereby all web applications share the
same service applications.
You can modify which service application connections are contained in a service application group by
using either of the following methods:
The Configure service applications associations page in Central Administration
The Add-SPServiceApplicationProxyGroupMember and RemoveSPServiceApplicationProxyGroupMember Windows PowerShell cmdlets
Additional Reading: For more information, see Add or remove service application
connections from a web application in SharePoint 2013 at
You can also use Central Administration to change the service application group that a web application is
associated with. On the Manage web applications page, select the web application in the list and click
Service Connections on the ribbon.
Creating Web Applications

When you create a new web application in
SharePoint 2013, you also create a new content
database and specify which mechanism to use to
authenticate users of the web application.
Using classic-mode authentication is not
recommended in SharePoint 2013; claims-based
authentication is the default, and preferred, user
authentication mechanism. Claims-based
authentication is needed to support advanced
authentication capabilities such as server-to-server
authentication and app authentication.
Creating a claims-based web application

You can either use Central Administration or Windows PowerShell to create claims-based web
applications. However, if you are creating or configuring a web application that uses classic-mode
authentication, you must use Windows PowerShell.
To create a claims-based web application in Central Administration:
Use an account that is a member of the Farm Administrators SharePoint group.
In SharePoint 2103 Central Administration, open the Manage web applications page.
Create a new web application and supply the following information:
6-8
Name of the new IIS website.
Port number you want to use to access the web application (for example, port 80 is the default
port for HTTP access).
A host header if required.
Path to the IIS website home directory on the server. (When creating a new website, this field
already contains a suggested path).
Select the claims-based authentication method to use for the new web application.
Choose one of the Sign In Page URL options.
Choose a Public URL for the domain name for all sites that users will access in this web
application. This URL will be used as the base URL in links that are shown on pages within the
web application.
Choose an application pool.
Choose the database server, database name, and database authentication method for your new
web application.
Select the service application connections that will be available to the web application, for
example; default.
To create a claims-based web application by using Windows PowerShell:
In SharePoint 2013 Management Shell, create a claims-based authentication provider using the NewSPAuthenticationProvider cmdlet, as shown here.
$ap = New-SPAuthenticationProvider
In SharePoint 2013 Management Shell, create a claims-based web application using the
New_SPWebApplication cmdlet, as shown here.
New-SPWebApplication -Name <Name>
-ApplicationPool <ApplicationPool>
-ApplicationPoolAccount <ApplicationPoolAccount>
-Port <Port> -URL <URL> -AuthenticationProvider $ap
Where:
<Name> is the name of the new web application that uses claims-based authentication.
<ApplicationPool> is the name of the application pool.
<ApplicationPoolAccount> is the user account that this application pool will run as.
<Port> is the port on which the web application will be created in IIS.
<URL> is the public URL for this web application.
Additional Reading: For more information about creating a claims-based web application,
see Create claims-based web applications in SharePoint 2013 at
Creating a classic-mode web application
Although you can create claims-based web applications with either Central Administration or Windows
PowerShell, if you are creating or configuring a web application that uses classic-mode authentication,
you must use Windows PowerShell.
To create a web application that uses classic-mode authentication with Windows PowerShell:
In SharePoint 2013 Management Shell, create a classic-mode web application using the
New_SPWebApplication cmdlet, as shown here.
New-SPWebApplication -Name <Name>
-ApplicationPool <ApplicationPool>
-AuthenticationMethod <WindowsAuthType>
-ApplicationPoolAccount <ApplicationPoolAccount>
-Port <Port> -URL <URL>
Where:
<Name> is the name of the new web application that uses claims-based authentication.
<ApplicationPool> is the name of the application pool.
<WindowsAuthType> is either NTLM or Kerberos. Kerberos is recommended.
<ApplicationPoolAccount> is the user account that this application pool will run as.
<Port> is the port on which the web application will be created in IIS.
<URL> is the public URL for this web application.
Additional Reading: For more information about creating a classic-mode web application,
see Create web applications that use classic mode authentication in SharePoint 2013 at
Web Application Zones

Often, you have an IIS website that you want to
provide to multiple user types, such as intranet
users and Internet users. Because you would
typically need different authentication
mechanisms for each user type, you can extend
your web application to make it available from
different URLs. One way to accomplish this is to
extend the web application into different zones.
Web application zone types

There are five different possible zones for a web
application in SharePoint 2013:
Default
Intranet
Internet
Custom
6-9
Extranet
Note: These zone names are arbitrary and do not have any particular meaning. There are
no properties or conditions associated with any of the zone names.
6-10 Creating Web Applications and Site Collections
The Default zone is created when you first create the web application; the other zones are created when
you extend a web application to one of those zones.
Note: It is only possible to select each zone type once in a web application. For example,
after you have extended a web application to the Internet zone, you cannot extend the web
application to another Internet zone.
When you extend a web application to one of these zones, you actually create a new separate IIS website
that serves the exact same content as other websites in your web application, but they will each have their
own unique URL to connect to and can also use different authentication methods.
So, for example, if you wanted to host a website for users in your own organization and allow them to be
authenticated and to access and edit content based on their credentials and privileges, you would extend
your web application to an Intranet zone, but if you also wanted your customers to access the site using
anonymous access, you would also extend the web application into an Internet zone. Essentially, it is a
way of providing a single site differently, based on the URL that the user uses to access the site.
Web application zones provide a way for you to partition site access based on authentication type; such as
claims-based or classic-mode, by network type; such as intranet and extranet, and even by policy
permissions; such as allowing or denying write access.
Note: It is worth noting that this feature is not used as much as it used to be in previous
versions of SharePoint because there are now other ways of doing a very similar thing; for
example, you can associate multiple authentication providers with a single web application in a
single zone.
Extending a web application to a new zone

You can use Central Administration to extend a web application to a new zone by selecting the web
application on the Manage web applications page in Application Management, and then clicking
Extend on the ribbon. From here, you can select any of the remaining available zones for your web
application.
You can also use the New-SPWebApplicationExtension Windows PowerShell cmdlet to extend a web
application to another zone.
Additional Reading: For more information about the steps to extend a web application to
a new zone in Central Administration and Windows PowerShell, see Extend a Web application
(SharePoint Server 2010) at http://go.microsoft.com/fwlink/?linkid=299608 This article was
written for SharePoint 2010, but the procedures remain mostly unchanged.
Discussion: Creating a New Web Application

Under what circumstances would you want to
create a new web application?
Discussion: Extending a Web Application to a New Zone

Under what circumstances would you want to
extend a web application to a new zone?
6-11
Lesson 2
Configuring Web Applications
In this lesson, you will learn about web application configuration in a SharePoint 2013 environment. This
includes key web application configuration settings such as managed paths, Alternate Access Mappings
(AAM), Resource Throttling, quota templates, self-service site creation, and customization.
Lesson Objectives
Understand web application configuration.
Manage content databases.
Configure managed paths.
Configure Alternate Access Mappings.
Configure Resource Throttling.
Configure quota templates.
Configure self-service site creation.
Configure support for customization.
Overview of Web Application Configuration

There are numerous settings you can use to
configure web applications in SharePoint 2013 to
meet your organizations business requirements.
These settings can be set using Central
Administration or Windows PowerShell cmdlets.
These settings are introduced here and then
covered in greater detail throughout the
remainder of this module.
Override farm configuration settings

In SharePoint 2013 Central Administration, there
are several web application settings that can be
configured at the farm-level.
For example, if you open Application Management and access the Manage web applications page, you
can select a web application and click the General Settings button on the ribbon. From here, you can
maintain Outgoing E-mail and Mobile Account settings:
Outgoing E-mail. This setting configures an outbound Simple Mail Transfer Protocol (SMTP) server so
that you can use email-based administrator and user notifications, and user alerts and invitations, in
your web application. When you configure this setting for a web application, you will override the
farm-level settings for this web application only.
Mobile Account. This setting configures a mobile account for a single web application to enable users
to subscribe to SMS alert services provided by a mobile service provider. When changes occur on
SharePoint items and lists, these SMS alerts are sent to your users mobile devices.
Note: When configuring mobile accounts for SharePoint 2013, you can either configure
one mobile account for all the web applications in a farm, or you can configure one mobile
account for one specific web application. However, you cannot configure both.
If you choose to configure one mobile account for all web applications, all your users have the ability to
subscribe to SMS alerts. However, if you have an environment where your web applications are split by
department, you may want to limit the subscription to SMS alerts to only one department, such as your
sales team. In this scenario, you would configure the mobile account for the sales team web application.
Manage security
The following four settings affect the security of a web application:
Policies. These permission policies provide a method for you to centrally configure and manage a set
of permissions that applies to only a subset of users or groups for a single web application. There are
three policy areas you can configure for a web application:
o
User Policy. This is a set of broad permissions that you can configure for users or groups. You can
grant Full Control, Full Read, Deny Write, and Deny All permissions, and you can specify which
web application zone they should apply to. Web applicationlevel user policies are often used to
grant Full Read permissions to the search crawler account.
Anonymous Policy. This defines an anonymous access policy for your web application. You can
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 anonymous access is disabled for a web application, no sites
within that web application can be accessed by anonymous users. The permissions you can grant
in an anonymous user policy are None, Deny Write, and Deny All.
Permission Policy. This defines advanced user permission policies for a web application in terms
of permission policy levels. You can either select from one of the four default permission policy
levelswhich are the same as the permissions in the User Policy areaor you can create your
own custom permission policy levels.
Web Part security. This setting defines the default Web Part settings for the site collections in a web
application. You can configure whether users can create connections between Web Parts, whether
users can access the Online Web Part Gallery, and whether you will allow contributors to add or edit
scriptable Web Parts.
User permissions. This setting defines granular user permissions for lists, sites, and views in a web
application.
Blocked file types. This setting defines the file types that users are disallowed from adding to a web
application.
Manage load
There are several settings you can configure for a web application that can help control the load placed
on the web application. The following settings are configured by clicking the General Settings button in
the ribbon on the Manage web applications page:
Default quota template. This setting defines the default quota template used by all the site collections
contained in this web application.
Alerts. This setting defines the default settings for alerts on this web application. You can turn alerts
on or off and specify either a maximum number of alerts a user can create, or an unlimited number.
Maximum upload size. This setting defines the maximum size that you will allow for any single upload
to any site in this web application. This maximum upload size is not just for single files; it also counts
when uploading a group of files whose combined size is greater than this limit value.
There are also several Resource Throttling settings that can be configured under the General Settings,
Resource Throttling menu item on the ribbon of the Manage web applications page.
Additional Reading: For more information about Resource Throttling, see Planning and
Configuring Resource Throttling later in this lesson.
Manage Configurability and Customization

The following settings can help you manage the configurability and customization of your web
applications in SharePoint 2013:
SharePoint Designer settings. These settings are specifically targeted at the use of SharePoint
Designer. Because SharePoint Designer is such a powerful and flexible tool, it allows the appearance
or functionality of a site to change, and this can cause some inherent site issues; these settings are
designed to help you mitigate those issues.
Workflow settings. These settings manage web application workflow settings. Using these settings,
you can enable or disable user-defined workflows for all the sites in this web application, you can
define whether users without site access are notified of workflow task assignments, and whether to
send copies of documents in the workflow to external users.
Self-Service Site Creation. This setting defines and manages your users ability to create their own site
collections in a defined URL namespace. This is commonly used in the My Sites web application.
Additional Reading: For more information about SharePoint Designer and workflow
settings, see Planning for Customization later in this lesson. For more information about SelfService Site Creation settings, see Planning and Configuring Self-Service Site Creation later in this
lesson.
Managing Content Databases

When you create a web application on the
Manage web applications page in Central
Administration, or if you use the NewSPWebApplication Windows PowerShell cmdlet
to create your web application, you must specify
the name of the initial content database. This
creates the database, and you can later add
additional content databases for the web
application.
Adding content databases
When adding content databases, you can either

add a new content database or attach an existing
content database from a backup file. You can add content databases to a SharePoint 2013 farm by using
either Central Administration or Windows PowerShell.
In Central Administration, on the Application Management page, under Databases, you click Manage
content databases to add a content database. In Windows PowerShell, you use the NewSPContentDatabase cmdlet to add a content database.
Additional Reading: For more information about adding content databases in SharePoint
2013, see Add content databases in SharePoint 2013 at
Attaching and detaching content databases
There may be occasions when you want to attach or detach a content database, such as when you need
to add a new content database to a new site collection to retain your content databases at a manageable
size. You may also want to restore a content database from another farm and you want to be able to
access the sites contained in the content database from a web application.
You can attach or detach SharePoint 2013 content databases by using Central Administration or Windows
PowerShell.
To attach an existing content database to a web application, use the Mount-SPContentDatabase
Windows PowerShell cmdlet. To detach a content database from a web application, use the DismountSPContentDatabase Windows PowerShell cmdlet.
Note: For more information, see Attach or detach content databases in SharePoint 2013 at
Note: After detaching a content database in Central Administration, the content database
will still exist in SQL Server. To permanently remove the content database, you must use a SQL
Server procedure.
Backing up and restoring content databases
Content databases on SharePoint 2013 farms can become very large over time. Therefore, it is likely that
you will want to back them up separately from your farm backups.
Note: You can back up only one content database at a time.
You can back up a content database in Central Administration by clicking Perform a backup, under
Backup and Restore. You can also use the Backup-SPFarm Windows PowerShell cmdlet to back up a
content database.
Additional Reading: For more information about using Central Administration or
Windows PowerShell to back up a content database, see Back up content databases in SharePoint
You can restore a content database in Central Administration by clicking Restore from a backup, under
Backup and Restore. You can also use the Restore-SPFarm Windows PowerShell cmdlet to restore a
content database. You can restore a content database or several content databases, but you can only
restore one at a time.
Additional Reading: For more information about using Central Administration or

Windows PowerShell to restore a content database, see Restore content databases in SharePoint
You also have the option of backing up and restoring a content database by using SQL Server tools.
Additional Reading: For more information about backing up a content database with SQL
Server tools, see Use SQL Server tools to back up a content database in SharePoint 2013 in Back
up content databases in SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299611
For more information about restoring a content database with SQL Server tools, see Using SQL
Server tools to restore a SharePoint content database in Restore content databases in SharePoint
Planning and Configuring Managed Paths

To create a new site collection within a web
application, there must be a managed path in
which the site collection can be created.
Managed paths
A managed path is a portion of the Uniform
Resource Indicator (URI) namespace where the site
collections exist. A managed path is not directly
mapped to content within the web application.
Instead, it is used by SharePoint as a namespace
(path) node where site collections can be created.
You can specify that one or more site collections
exists at a specific path. This can be a useful way of
consolidating multiple site access for users in different departments.
An explicit managed path is useful for creating only a single site collection, at the exact URL specified. For
example, the default (root) managed path for an intranet site might be http://intranet.litware.com/ and a
single site collection can be created at that exact URL.
A wildcard managed path, for example, http://intranet.litware.com/sites/ indicates that child URLs of the
path are site collections. A wildcard managed path such as sites/ allows for an unlimited number of site
collections to be created directly under the provided path. It is important to note that a site collection,
and therefore a website, cannot be created at this explicit URL.
Configuring managed paths
To use Central Administration to configure managed paths, under Application Management, click
Manage web applications, click the web application in the list, and then click Managed Paths on the
ribbon.
To configure managed paths for a web application in Windows PowerShell, use the NewSPManagedPath cmdlet.
Additional Reading: For more information about managed paths, see Define managed
paths (SharePoint Server 2010), at http://go.microsoft.com/fwlink/?Linkid=299613 (this article
was written for SharePoint 2010, but the procedures remain mostly unchanged), and SharePoint
101: Managed Paths at http://go.microsoft.com/fwlink/?Linkid=299614
Planning and Configuring Alternate Access Mappings

Alternate Access Mapping (AAM) is a feature that
enables a SharePoint website to be accessed
through different URLs. AAMs can be used when
accessing through a reverse proxy, from an
intranet, from the Internet, or in a load balanced
farm. SharePoint uses AAM to map selected web
requests to the corresponding web application
and site, which allows SharePoint to deliver the
correct content to the browser.
AAM deprecation in SharePoint 2013
6-17
Although AAM is still available and supported in

SharePoint 2013, it is deprecated in this release.
The recommended alternative in SharePoint 2013 is the use of host header site collections, or host named
site collections in a single web application. This feature provides functionality similar to AAM by allowing
you to associate multiple URLs with a single host header site collection or a host named site collection.
You can then use Windows PowerShell cmdlets, such as Get-SPSiteURL and Set-SPSiteURL, to manage
the URLs in these host header sites and host named site collections. You can still use zones in conjunction
with a sites URLs to enable different authentication mechanisms to be used.
Configure AAMs
You use the Configure alternate access mappings item under System Settings in Central
Administration to configure AAM for your farm.
On the Alternate Access Mappings page, you can edit existing public URLs, add internal URLs, and
create external resource mappings:
Edit Public URLs. When you configure public URLs, you can choose from five different zones: Default,
Intranet, Internet, Custom, and Extranet. The Default zone URL must be defined, but you can add any,
or all, of the others.
Add Internal URLs. When you add internal URLs, you specify the protocol, host, and port of the URL
that should be associated with this resource, and you specify the web application zone.
Map to External Resources. When you add external resource mapping, you specify a unique resource
name and an initial URL protocol, host, and port.
You can also configure AAM by using the Get-SPAlternateURL and New-SPAlternateURL Windows
PowerShell cmdlets.
Additional Reading: For more information about configuring AAM, see How Do I:
Configure an Alternate Access Mapping in SharePoint 2010? at
http://go.microsoft.com/fwlink/?Linkid=299615 . This article was written for SharePoint 2010, but
the procedures remain mostly unchanged.
Discussion: Using Alternate Access Mapping

In what circumstances might you still want to use
Alternate Access Mapping?
Planning and Configuring Resource Throttling

If one of your web servers becomes fully loaded
with HTTP requests because of a lack of system
resources, requests start getting added to the
request queue. The request queue will then start
to fill up, and eventually the server will not be able
to cope with any more requests, so when server
resources are stretched to their maximum,
requests will start to get dropped.
HTTP Request Monitoring and

Throttling
In SharePoint 2013 you can use one of the

Resource Throttling features named HTTP Request
Monitoring and Throttling, also referred to as HTTP Throttling, to help ease the strain on your front-end
web servers when request traffic is high and your farm starts to suffer from poor performance and
response times.
HTTP Request Monitoring and Throttling works by monitoring the system resources on your server, such
as the CPU, memory, and wait time, and checking them at regular intervals. When an HTTP request
overload occurs, it will start to reject, or throttle, lower priority requests, such as search crawl requests, to
ease the queue.
You set HTTP Request Monitoring and Throttling at the web application level, and for all new web
applications, it is turned on by default. You use Central Administration to turn on or turn off the feature.
Perform the following steps to enable HTTP Request Monitoring and Throttling in Central Administration:
1.
Start SharePoint 2013 Central Administration.
2.
On the SharePoint Central Administration website, click Application Management.
3.
On the Application Management page, click Manage web applications.
4.
Select the web application you want to configure Resource Throttling for.
5.
On the drop-down menu, click General Settings.
6.
Click Resource Throttling.
7.
Scroll down the page, and in the HTTP Request Monitoring and Throttling section, click On.
8.
Click OK.
Additional Reading: You can also use Windows PowerShell cmdlets to view and edit
thresholds for settings in Resource Throttling. For more information, see GetSPWebApplicationHttpThrottlingMonitor at http://technet.microsoft.com/enus/library/ff607834.aspx and Set-SPWebApplicationHttpThrottlingMonitor at
http://technet.microsoft.com/en-us/library/ff607944.aspx.
List throttling
The Request Throttling feature just described can also be used to configure a List View Threshold for large
lists to prohibit database operations that involve too many items, such as queries that return a large
number of items or adding a column to a list that contains a large number of items.
List throttling is turned on by default in SharePoint 2013 and the default value for List View Threshold is
5000. When the number of items in a list exceeds this value, users receive a warning when they browse
the List Settings page.
To access the following list throttling settings in SharePoint 2013, navigate to Central Administration, click
Manage web applications (under Application Management), click General Settings, and then click
Resource Throttling on the ribbon:
List View Threshold. This setting defines the maximum number of items that can be involved in a
single database operation. Any database operations that exceed this limit are prohibited.
Object Model Override. This setting allows users with the appropriate permissions to be able to
override the List View Threshold setting programmatically for specific queries.
List View Threshold for Auditors and Administrators. This setting defines the maximum number of
items that can be involved in a single database operation for users who are either auditors or
administrators. Any database operations that exceed this limit are prohibited. The default value is
20,000 items.
Daily Time Window for Large Queries. This setting defines the window of opportunity when large
queries can be executed in the web application. Typically, this setting is set outside of working hours
to avoid excessive loads on the server, and is often referred to as happy hour.
Additional Reading: For more information about throttling for large lists, see Designing
large lists and maximizing list performance (SharePoint Server 2010) at
http://go.microsoft.com/fwlink/?Linkid=299616 This article was written for SharePoint 2010, but
Planning and Configuring Quota Templates

One of the most important site collection settings
is the quota template associated with the site
collection.
A quota template specifies the maximum storage
permitted for each site in a site collection.
Quota templates and quotas

Quotas define the following:
Storage limit (in MB)
Storage warning level at which site collection

owners (primary and secondary site collection
administrators) are notified that the site is approaching its storage limit. This value must be lower
than the storage limit.
Resource usage limit for Sandboxed Solutions (per day).
Resource usage warning level at which site collection owners (primary and secondary site collection
administrators) are notified that the site is approaching its resource usage limit. This value must be
lower than the resource usage limit.
Default quota templates

You configure the default quota template used by all site collections at the web application level. In
Central Administration, under Application Management, open the Manage web applications page,
select the web application you want to define the default quota template for, and then click General
Settings on the ribbon. On the Web Application General Settings page, in the Default Quota
Template section, select the quota to use as the default for the entire web application.
Create or modify a quota template
Quota templates are defined at the farm level. When you create a quota template, you simplify the
management of storage limits on all new site collections in the web application. If you have one or more
sites that have different storage and performance needs than other sites in the site collection, you might
want to create a new quota template to apply to those sites.
You can create a new quota template in Central Administration, under Application Management. In the
Site Collections section, click Specify quota templates. You can create, modify, or delete a quota
template on the Quota Templates page.
Note: There are no out-of-the-box Windows PowerShell cmdlets to create quota
templates.
Additional Reading: For more information about creating quota templates, see Create,
edit, and delete quota templates (SharePoint Server 2010) at
Applying quota templates

Quota templates are applied at the site collection level.
Additional Reading: For more information about applying quota templates to a site
collection, see Applying Quota Templates to Site Collections later in this module.
Planning and Configuring Self-Service Site Creation

Enabling Self-Service Site Creation allows users
with the appropriate permissions to create site
collections in defined URL namespaces without the
need to provide them with access to Central
Administration. Self-Service Site Creation enables
the automatic creation of a separate site collection
for users when they first view their My Site
personal site.
Enabling Self-Service Site Creation for

the My Sites web application
6-21
You must turn on Self-Service Site Creation for the

My Site web application; otherwise, your users will
not be able to create My Sites. Self-Service Site Creation is not usually enabled for other web applications.
Perform the following steps to enable Self-Service Site Creation for the My Sites web application:
1.
Log on as a member of the Farm Administrators group.
2.
Open Central Administration.
3.
Under Application Management, click Manage web applications.
4.
On the Web Applications page, select the web application that you created to host My Sites.
5.
On the WEB APPLICATIONS tab, in the Security group, click Self-Service Site Creation.
6.
In the Self-Service Site Creation Management dialog box, in the Site Collections section, click On,
which allows your users to create site collections in the defined URL namespace.
7.
Under Quota template to apply, select a quota template, if required.
8.
Under The Start a Site link should, click Prompt users to create a team site under, and then
provide the path to the subsite from where you host your users My Sites; for example,
http:/mysites.litware.com/personal. This setting gives your users a shortcut to create new Team Sites
from their My Sites.
9.
Click OK.
After Self-Service Site Creation is enabled for the My Sites web application, users can go to
http://rootsite/_layouts/15/scsignup.aspx to create a new site. This link opens the New SharePoint Site
page. You can view and open this link on the Self-service Site Collection Management page, when you
click Configure self-service site creation in the Application Management section of Central
Administration.
Planning for Customization

SharePoint Designer is a powerful application that
you can use to quickly build complex SharePoint
solutions, such as collaboration sites, publishing
sites, business intelligence (BI) solutions, and
workflows.
SharePoint Designer and SharePoint

2013
SharePoint Designer has been enhanced in its
most recent version, SharePoint Designer 2013, to
include new workflow functionality. This feature
set is specifically designed to work with the new
Workflow Manager service in SharePoint 2013,
known as the SharePoint 2013 Workflow platform.
Because SharePoint Designer is such a powerful and flexible tool, which allows the appearance or
functionality of a site to change, it can bring with it some inherent site issues including:
Pages becoming detached from their site definition.
Corporate branding accidentally being removed from a site collection through customized master
pages and layout pages.
Support or template files accidentally being removed directly from the site URL structure.
SharePoint Designer settings pages
To guard against these potential problems, SharePoint 2013 provides some settings specifically targeted
at SharePoint Designer; these are found in two places in SharePoint 2013:
Central Administration > General Application Settings > Configure SharePoint Designer settings.
These settings define SharePoint Designer settings for the entire web application.
Site Settings > Site Collection Administration > SharePoint Designer Settings. These settings define
SharePoint Designer settings for only the site collection you configure them in.
Each of these settings pages contains the four key settings for SharePoint Designer. At the web
application level, they apply to all site collection administrators, and at the site collection level, they apply
to all site owners and designers for that site collection. The following are the four key settings:
Enable SharePoint Designer. This setting specifies whether SharePoint Designer is enabled or disabled
for the web application or site collection. When this option is selected, users can edit sites in this web
application or site collection with SharePoint Designer.
Enable Detaching Pages from the Site Definition. This setting specifies whether users are allowed to
detach pages from the original site definition. When this option is selected, users can use SharePoint
Designer to edit pages in Advanced Mode, which gives them access to all parts of the page; therefore,
when they save the page, it can become detached from its site definition. If this option is not selected,
SharePoint Designer disables the Advanced Mode, which then forces the users to edit only the parts
of the page that are in a Web Part zone; as a result, the page will never be detached from the site
definition.
Enable Customizing Master Pages and Layout Pages. This setting specifies whether users are allowed
to customize master pages and page layouts in SharePoint Designer. When this option is selected,
SharePoint Designer displays the master pages and page layouts in the Navigation pane, and when it
is unchecked these pages do not appear.
Enable Managing of the Web Site URL Structure. This setting specifies whether users are allowed to
manage the URL structure of the website and its contents. When this option is selected, the All Files
option is displayed in the Navigation pane in SharePoint Designer, which allows users to view and edit
any file on the site. If this option is not selected, the All Files option does not appear in the
Navigation pane.
Workflow settings
These settings define web application workflow settings. You can enable or disable user-defined
workflows for all the sites in this web application, you can define whether users without site access are
notified of workflow task assignments, and you can define whether copies of documents in the workflow
are sent to external users.
Configuring workflow settings
You can configure workflows settings at the web application level, using Central Administration. Under
Application Management, click Manage web applications, click your web application, click the
General Settings drop-down menu on the ribbon, and then click Workflow.
The workflow settings are:
Enable user-defined workflows for all sites on this web application. This defines whether your users can
assemble new workflows out of reusable code deployed to the site by the administrator. This option is
selected by default.
Alert internal users who do not have site access when they are assigned a workflow task. This setting
defines whether users without site access receive email notifications about workflows and pending
workflow tasks. This option is selected by default.
Note: For each user who is not a site member, you must also grant at least Contribute
permissions to the task list that is used by the workflow that you want them to participate in.
Allow external users to participate in workflow by sending them a copy of the document. This option
is not selected by default.

Scenario
server farm consists of three servers: a domain controller, a SQL Server 2012 deployment, and a
SharePoint 2013 server. The team has configured the SharePoint farm, including incoming and outgoing
email and Office Web Apps Server integration. Your task is to create new web applications for the sales
and finance teams. You will define subdomains to host each web application, and then you will create and
configure the web applications. The finance team supports all of Contosos global operations and must
comply with different legislation in different countries. To ease this process, you will define a managed
path named Country to enable the finance team to use a different site collection for each country. Use an
easy-to-read address, such as finance.contoso.com/Country/US or finance.contoso.com/Country/UK.
Finally, you will configure an outgoing email address for each new web application so that email
messages sent by using these web applications are easily identifiable from other email messages sent by
SharePoint.
Objectives
Create a SharePoint 2013 web application.
Configure SharePoint 2013 web application settings.
Virtual Machine: 20331B-NYC-DC-06, 20331B-NYC-DB-06, 20331B-NYC-SP-06
User Name: [email protected]
Password: Pa$$w0rd
Exercise 1: Creating a Web Application

Scenario
In this exercise, you will create new web applications by using the Central Administration website. You will
configure DNS and create service accounts on the domain controller.
You will then assign additional IP addresses to the SharePoint web server, for use by the new web
applications. You will use the Central Administration website to register the service accounts as SharePoint
managed accounts. You will then create the new web applications.
Finally, you will disable loopback checking for the domains used by the new web applications to ensure
you can browse to the web applications on the SharePoint server.
1. Configure DNS for the new web applications
2. Create service accounts for the web applications
3. Assign additional IP addresses to the SharePoint Server
4. Register the new service accounts as SharePoint managed accounts
5. Create the web applications
6. Disable loopback checking for the required domains
Task 1: Configure DNS for the new web applications
Log on to the 20331B-NYC-DC-06 machine as [email protected] with the password

Pa$$w0rd.
Open DNS Manager.
Name
IP address
sales
172.16.1.40
Name
IP address
finance
172.16.1.41
Create a new forward lookup zone named sales.
Add a new host record to the sales forward lookup zone with the following properties.
Name
IP address
172.16.1.40
Create a new forward lookup zone named finance.
Add a new host record to the finance forward lookup zone with the following properties.
Name
IP address
172.16.1.41
Task 2: Create service accounts for the web applications

Full name
Sales Web App Service Account
UPN logon
[email protected]
contoso\SPSalesWebApp
Password
Pa$$w0rd
Selected
Full name
Sales Web App Service Account

Selected

Full name
Finance Web App Service Account
UPN logon
[email protected]
contoso\SPFinanceWebApp
Password
Pa$$w0rd
Selected
Selected
Task 3: Assign additional IP addresses to the SharePoint Server
[email protected] with the password Pa$$w0rd.
Open Network Connections to view the network adapters installed on this server.
Add the following additional IP addresses to the Ethernet network adapter:

o
172.16.1.40
172.16.1.41
Task 4: Register the new service accounts as SharePoint managed accounts
Use the Central Administration website to register the contoso\SPSalesWebApp account you
created in the previous tasks as a managed account.
Register the contoso\SPFinanceWebApp account you created in the previous tasks as a managed
account.
Task 5: Create the web applications
Create a new web application with the following properties.

IIS website name
SharePointSales - 80
Port
80
Host header
Sales.local
Path
C:\inetpub\wwwroot\wss\VirtualDirectories\Sales80
Application pool name
SharePointSales - 80
Application pool security

account
CONTOSO\SPSalesWebApp
Note: You will use the sales.local domain for the sales web application. This domain is not
configured in DNS, so you would need to make changes not included in this lab if you wanted to
browse to this domain. You will use host-named site collections with this web application, with
host names that are correctly configured in DNS. The local top-level domain is used as a
placeholder for this lab and has no special meaning. You could replace this with any other toplevel domain, including a domain which is configured in DNS according to your requirements.

Port
80
Host header
finance.contoso.com
SharePointFinance - 80
Application pool security

account
CONTOSO\SPFinanceWebApp
In Internet Information Services (IIS), add a binding to the SharePointSales 80 website that binds it
to the 172.16.1.40 IP address on port 80. You should not specify a host name.
In IIS add a binding to the SharePoint finance.contoso.com website that binds it to the
172.16.1.41 IP address on port 80. You should not specify a host name.
Task 6: Disable loopback checking for the required domains
In the registry, disable loopback checking for the sales.contoso.com domain to enable you to visit
the site on the SharePoint server.
Disable loopback checking for the sales domain.
Disable loopback checking for the finance.contoso.com domain.
Disable loopback checking for the finance domain.
Restart Internet Information Services (IIS).
Results: After completing this exercise, you should have created new web applications on the SharePoint
server. You should have created the necessary service accounts, and configured DNS, and then configured
the SharePoint server to permit browsing custom domains on the SharePoint server.
Exercise 2: Configuring a Web Application

Scenario
In this exercise, you will add a new managed path to a web application. You will then configure the
outgoing email address for the web application.
1. Add a new managed path to the finance.contoso.com web application
2. Configure the outgoing email address for the web applications
Task 1: Add a new managed path to the finance.contoso.com web application
On the Central Administration website, browse to the Web Applications Management page.
Add a managed path named country to the finance.contoso.com web application.
Task 2: Configure the outgoing email address for the web applications
Set the outgoing email address for the finance.contoso.com web application to
[email protected].
Set the outgoing email address for the SharePointSales - 80 web application to
[email protected].
Results: After completing this exercise, you should have configured outgoing email settings and managed
paths for a web application.
Lesson 3
Creating and Configuring Site Collections
6-29
In this lesson, you will learn about site collection concepts and how to create site collections in your
SharePoint 2013 environment. You will also learn how to create host-named site collections, how to apply
quota templates to site collections, manage site and site content life cycles, and manage site mailboxes.
Lesson Objectives
Understand site collection concepts.
Create site collections.
Create host-named site collections.
Apply quota templates to site collections.
Manage site and content life cycles.
Manage site mailboxes.
Site Collections in SharePoint 2013

A site collection is a group of SharePoint websites
that share common ownership and top-level
administrators, as well as common settings, such
as quotas and locks. When you create a site
collection, you also create a top-level site in the
site collection.
You can create any number of subsites in a
hierarchy under the top-level site, and a subsite
can inherit permissions and navigation from its
parent site, or you can specify them directly at the
subsite level. Site collections must be created by
site collection administrators, but subsites can be
created by any users who have been delegated the right to do so.
Site templates
When you create a new site in SharePoint 2013, you can start with a blank top-level site by choosing
Custom as your template, and then selecting a template later. However, it is more common to choose a
template such as Team Site or Publishing Portal to base the new site on. Templates consist of site
components such as pages, lists, and libraries that support an organizations needs, such as collaboration,
content publishing, records management, and business intelligence.
The site templates available in SharePoint 2013 are grouped into the following categories:
Collaboration. This category contains the following templates:

o
Team Site
Blog
Developer Site
Project Site
Community Site
Enterprise. This category contains the following templates:

o
Document Center
eDiscovery Center
Records Center
Business Intelligence Center
Enterprise Search Center
My Site Host
Community Portal
Basic Search Center
Visio Process Repository
Publishing. This category contains the following templates:

o
Publishing Portal
Enterprise Wiki
Product Catalog
Custom. Select this category to create a blank site and select a template later.
Site collections as security and administration boundaries
Site collections are used to provide a security boundary between one collection of sites and another. They
each have their own collection of SharePoint groups and permissions.
Site collections are also used to create a boundary for management and administration; each site
collection has its own Site Collection Administrator role, with at least one user in that role, so this can be
very useful in large organizations where you need to distribute site collection administration. A site
collection administrator has full control rights of the whole site collection; the top-level site, all of its
subsites, and all lists and libraries in the site collection.
Site collection owners
Site collection ownersthe primary and secondary site collection administrators of a site collection
receive quota and auto-deletion notices. In addition, they have all the rights associated with site collection
administrators.
Perform the following steps to assign site collection ownership in Central Administration:
1.
In Central Administration, navigate to Application Management > Site Collections > Change site
collection administrators.
2.
On the Site Collection Administrators page, select the site collection that you want to assign
ownership to.
3.
Specify primary and secondary site collection administrator user names.
Perform the following steps to assign site collection owners in Windows PowerShell:
1.
Open the SharePoint 2013 Management Shell.
2.
Use the Set-SPSite cmdlet with the OwnerAlias and SecondaryOwnerAlias switches using the
following syntax.
Set-SPSite -Identity "<SiteCollection>" -OwnerAlias "<DOMAIN\User>"SecondaryOwnerAlias "<DOMAIN\User>"
Where:
<SiteCollection> is the URL of the site collection to which you want to add a site collection
administrator.
<DOMAIN\User> is the name of the user you want to add as a site collection owner.
The -OwnerAlias parameter defines the primary site collection administrator.
The -SecondaryOwnerAlias parameter defines the secondary site collection administrator.
Site collection administrators
Site collection administrators are administrators of the site collection. They are given full control of the
site collection and always have the ability to change permissions on objects within the site collection. They
also have permission to perform a wide range of administrative tasks within the site collection.
Perform the following steps to add site collection administrators in Central Administration:
1.
In the top-level site of a site collection, click the Settings icon, and then click Site settings.
2.
Under Users and Permissions, click Site collection administrators.
3.
Add the names of the site collection administrators to the Site Collection Administrators box.
Although you can assign only two site collection owners, primary and secondary, you can assign more
than two site collection administrators for a site collection.
Difference between site collection owners and site collection administrators
Site collection owners are assigned by a farm administrator in Central Administration and receive email
notifications related to site usage and quotas. Site collection administrators are added and removed by
site collection administrators in the site collection settings. Other than those differences, the permissions
and capabilities of site collection owners and site collection administrators are identical.
Assigning permissions to the top-level site
Each SharePoint site has at least three default groups: SharePoint Owners, SharePoint Members, and
SharePoint Visitors. These groups have Full Control, Edit, and Read permission, respectively. Assigning
these permissions defines what capabilities each user or group has on this site and all subsites that inherit
permissions.
Perform the following steps to assign permissions to the top-level site in Central Administration:
1.
In the top-level site of a site collection, click the Settings icon, and then click Site settings.
2.
Under Users and Permissions, click Site permissions.
3.
Click the name of a group to which you want to add members, for example, SharePoint Visitors.
4.
Click New.
5.
Add the name of each user or user group that you want to add to this SharePoint group.
6.
After you finish adding users, click Share.
Note: To give all authenticated users the ability to browse a site, add the Domain Users
group to the SharePoint Visitors group of the site.
Creating a Site Collection

When you create a site collection, a top-level site
is automatically created in the site collection. You
can then create one or more subsites below the
top-level site. You can create site collections using
either Central Administration or Windows
PowerShell cmdlets.
Create a site collection by using Central

Administration
Perform the following steps to create a site
collection in Central Administration:
1.
In Central Administration, navigate to

Application Management > Site Collections > Create site collections.
2.
Verify you are focused on the web application in which you want to create a site collection.
3.
Type a title, and optionally, a description for the site collection.
4.
Specify the web site address URL.
5.
Select an experience version and language for the site collection.
6.
Select the template category and the template that you want to apply to the top-level site of the new
site collection.
7.
Provide the user names of the primary and secondary site collection administrators.
8.
Select a quota template for the site collection.
Note: Typically, the top-level site that is automatically created for a site collection is
created using a site template such as Team Site or Publishing Portal. However, it is also possible
to create a blank top-level site; this is done by clicking the Custom tab, and then picking a
template later.
Create a site collection by using Windows PowerShell

Perform the following steps to create a site collection in Windows PowerShell:
1.
2.
Use the New-SPSite cmdlet with the Url and -OwnerAlias switches using the following syntax.
Get-SPWebTemplate
$template = Get-SPWebTemplate "STS#0"
New-SPSite -Url "<URL for the new site collection>" -OwnerAlias "<domain\user>"
-Template $template
Where:
<URL> is the URL of the site collection you want to create.
The -OwnerAlias parameters <domain\user> value defines the primary site collection administrator.
(The -SecondaryOwnerAlias parameter defines the secondary site collection administrator).
The -Template parameters value specifies the site definition for the top-level sitein this example,
STS#0, the Team Site template.
Deleting a site collection
6-33
When you delete a site collection, you permanently destroy all content and user information in the site
collection, which includes the top-level site and all subsites. You can delete site collections using either
Central Administration or Windows PowerShell cmdlets.
Perform the following steps to delete a site collection in Central Administration:
1.
In Central Administration, navigate to Application Management > Site Collections > Delete a site
collection.
2.
On the Delete Site Collection page, expand the list of site collections, and select the site collection
you want to delete.
3.
Under the URL list, click the relative URL of the site collection that you want to delete, and then click
OK.
4.
On the Delete Site Collection page, read the Warning section, and then delete the site collection.
Perform the following steps to delete a site collection in Windows PowerShell:

1.
2.
Use the Remove-SPSite cmdlet with the GradualDelete switch using the following syntax.
Remove-SPSite -Identity "<URL>" GradualDelete
Where:
<URL> is the URL of the site collection you want to delete.
The -GradualDelete parameter specifies that you use gradual deletion, which reduces the load on the
system during the deletion process when deleting very large sites.
Additional Reading: For more information about deleting site collections, see RemoveSPSite at http://go.microsoft.com/fwlink/?Linkid=299618
Creating Host Named Site Collections

SharePoint 2013 supports path-based and host
named site collections. In a web application
containing path-based site collections, all the site
collections share a common Domain Name System
(DNS) host name. Conversely, host named site
collections in a web application each have a
unique DNS host name; therefore, each has its
own top-level URL.
In web-hosting environments, each path-based

site collection would usually be assigned URLs
such as http://www.litware.com/sites/clientA,
http://www.litware.com/sites/clientB, and
http://www.litware/com/clientC. On the other hand, when using host named site collections, each host
named site collection would have its own vanity host name URL, such as http://clientA.litware.com,
http://clientB.litware.com, and http://clientC/litware.com.
SharePoint 2013 supports host named site collections as an alternative to creating individual site
collections for each client. Host named site collections have the scalability to allow a single web
application to host a very large number of site collections, while still providing a vanity naming solution.
In SharePoint 2010, host named site collections used a single URL, so they were always considered to be in
the Default web application zone. Host named site collections have been enhanced in SharePoint 2013 to
allow you to add multiple URLs by using the Set-SPSite cmdlet. The URLs will be mapped to one of the
five available web application zones, but you can now add multiple URLs to a zone. This means that multitenancy hosting scenarios, such as web hosting solutions, can now use numerous URLs without facing the
previous limitations.
How to create host named site collections
You cannot use Central Administration to create host named site collections; instead, you must use
Windows PowerShell cmdlets. However, Central Administration can be used to manage host named site
collections after you create them.
The procedures to create host named site collections and to add top-level URLs have been simplified in
SharePoint 2013 when using Windows PowerShell cmdlets.
You use the following Windows PowerShell cmdlets to create and manage host named site collections in
SharePoint 2013:
New-SPSite (with the -HostHeaderWebApplication switch). This enables you to create a host named site
collection and add a host name which is a top-level URL.
The -HostHeaderWebApplication switch identifies the web application where the site collection is to be
created.
Set-SPSiteUrl. This enables you to add new top-level URLs to a host named site collection.
Get-SPSiteUrl. This enables you to list all the top-level URLs assigned to a host named site collection.
Remove-SPSiteUrl. This enables you to remove a top-level URL assigned to a host named site
collection.
Applying Quota Templates to Site Collections

A site collection can be associated with one of the
farm's quota templates. When a new site is created
in the site collection section, the properties of the
quota templates are applied to the site.
To apply a quota template to a site collection in
Central Administration, open Application
Management, then under the Site Collections
section, click Configure quotas and locks. On the
Site Collection Quotas and Locks page, in the
Site Quota Information section, under Current
quota template, you can do one of two things:
Choose an existing template in the list. This

selects an existing quota template to use for the site collection.
Choose Individual Quota in the list. This enables you to manually configure individual quota settings
for the site collection.
6-35
You can use the Set-SPSite Windows PowerShell cmdlet with the QuotaTemplate switch to apply a
quota template to a site collection, and you can also use the Set-SPSite cmdlet with the MaxSize switch
to manually change storage limits for a site collection.
Additional Reading: For more information about how to apply quota templates to a site
collection, and how to manually configure individual quota limits for a site collection, see Create,
edit, and delete quota templates in SharePoint 2013 at
Managing Site and Content Life Cycle

SharePoint sites tend to be created as they are
required and are very rarely deleted when they are
no longer needed, so the number of sites tends to
increase very quickly in most SharePoint
environments.
Site policies in SharePoint 2013

Site policies in SharePoint are designed to help
control this site proliferation and bring an
organizations sites under control. Site policies
configure the life cycle of a SharePoint site by
defining when a site will be closed and when it will
be deleted.
The closing of sites is a new feature in SharePoint 2013. When you close a site, you are marking it as being
ready for deletion, based on a configured schedule. After it is closed, it does not appear in site
aggregation locations such as Exchange or Outlook, but until it is deleted, it is still reachable using the
URL directly in a browser.
Defining site policies
You define site policies for a site collection in the root site; these site policies are then available to all sites
in the site collection. Site policies are defined on the Site Policies page, from the Site Collection
Administration section in Site Settings, which is accessed by clicking the Settings icon, and then
clicking Site settings.
Note: SharePoint 2013 introduces the ability to close sites, with options to make the site
read-only and provide a grace period before the site is automatically deleted. However, you
cannot close a site without first creating a site policy and then applying it to the site collection.
Site policy options

A site policy defines the circumstances under which a site will automatically be closed or deleted.
The site closure and deletion policy options are as follows:
Do not close or delete site automatically. This policy option specifies that the site owner must manually
delete the site.
Delete sites automatically. This policy option specifies that a site owner can close the site manually,
but the site will be deleted automatically based on the deletion event settings specified.
Close and delete sites automatically. This policy option has the same choices as the preceding setting,
for deleting sites automatically, but it also enables you to specify how long after a sites creation date
the site will be closed.
You can also specify that when a site collection is closed, it becomes read-only, and visitors to the site will
be notified that it is closed and is in read-only mode.
Additional Reading: For more information about site policies and site policy options in
SharePoint 2013, see Overview of site policies in SharePoint 2013 at
http://go.microsoft.com/fwlink/?limkid=299620
Applying site policies
Site owners can apply a site policy to a site, and also close a site, by using the Site Closure and Deletion
page, which is accessed from Site Settings, under the Site Administration section.
Manually deleting a site
A site owner can use the Site Closure and Deletion page to see when a site will be deleted, based on the
site policy applied to it, but they cannot delete a site manually from here. To manually delete a site, a site
owner must choose Delete this site in the Site Actions section of Site Settings.
Site policies and Self-Service Site Creation
Using site policies in combination with Self-Service Site Creation is a very useful capability. There is a
setting in Self-Service Site Creation for a web application that enables a farm administrator to force users
to classify each new site they create and apply a policy to it. By using this combination, you can allow your
users to create their own sites, while also ensuring that the sites are deleted after a specified period of
time.
Site lock settings

You can use the lock status of a site collection to control the actions allowed on it. The available lock
states are:
Not locked. This status unlocks the site collection and makes it available to users.
Adding content prevented. This status prevents users from adding new content to the site collection,
but updates and deletions are still allowed.
Read-only (blocks additions, updates, and deletions). This status prevents users from adding, updating,
or deleting content. When a user attempts to perform any of these actions, they receive an error
message informing them that access is denied and that they do not have permission to perform the
action or access the resource.
No access. This status prevents users from accessing the site collection and its content.
You can view and configure the lock status of site collections in SharePoint 2013 Central Administration
by using the Configure quotas and locks page under Site Collections in the Application Management
section.
You can also configure the lock status of site collections by using the Set-SPSite Windows PowerShell
cmdlet with the LockState switch.
Managing Site Mailboxes

The Site Mailboxes feature in SharePoint 2013
provides users with team email on a SharePoint
site, and provides links to SharePoint document
libraries in Outlook 2013. This enables users to
share files and email messages with other team
members when they are working on projects
together. The feature is enabled through a
SharePoint App and can be added to any site.
Requirements for Site Mailboxes

There are several requirements for Site Mailboxes
to work in SharePoint 2013:
6-37
Exchange Server 2013 is required.
Previous versions of Exchange Web Services (EWS) need to be uninstalled from the SharePoint servers.
User profile synchronization needs to be configured in the farm.
The App Management service application needs be configured in the farm.
For web applications that are deployed in scenarios that support server-to-server authentication and
app authentication, Secure Sockets Layer (SSL) must be configured for the Default zone.
To configure Site Mailboxes, you must be a member of the SharePoint and Exchange Server
administrator groups and have an operational Exchange Server with end-user mailboxes.
Users who access files in a SharePoint document library from a Site Mailbox must have the document
library configured as a trusted site in their browser. If this is not configured, each time a user accesses
such a file they will get a warning message that asks them if they want to trust the file.
Configuring Site Mailboxes
There are several steps you must perform to enable and configure Site Mailboxes for SharePoint 2013:
1.
Install the Exchange Server Web Services API on each web front-end server in the SharePoint 2013
farm.
2.
Establish OAuth trust and service permissions on SharePoint 2013.
3.
Configure Exchange Server 2013 for site mailboxes by establishing OAuth trust and service
permissions on the Exchange server.
Additional Reading: For more information about configuring Site Mailboxes, see
Configure site mailboxes in SharePoint Server 2013 at

Scenario
server farm consists of three servers: a domain controller, a SQL Server 2012 deployment, and a
SharePoint 2013 server. Your team has installed SQL Server 2012 and SharePoint Server 2013. You have
created new web applications for the sales and finance teams. You defined a managed path named
Country to enable the finance team to use a different site collection for each country with an easy to read
address, such as finance.contoso.com/Country/US or finance.contoso.com/Country/UK. Finally, you will
configure outgoing email addresses for each new web application so that email messages sent by using
these web applications are easily identifiable from other email messages sent by SharePoint.
Objectives
Create a SharePoint 2013 site collection by using the Central Administration website.
Create a SharePoint 2013 site collection in a new content database by using Windows PowerShell.
Create a warm-up script for a SharePoint web server.
Lab Setup
Password: Pa$$w0rd
All Windows PowerShell cmdlet syntax is available for you to copy and paste in the Lab Answer Key
document. There is also a solution file (WarmUp.ps1) in the Mod06 folder in the Allfiles folder.
Exercise 1: Creating Site Collections

Scenario
In this exercise, you will create new site collections. You will create a top-level site collection by using the
Central Administration web site.
You will then use Windows PowerShell cmdlets to create host-named site collections. In addition, you will
create a site collection with multiple URLsa URL for internal use on the company intranet and a URL for
external use on the companies extranet.
Finally, you will test the site collections to verify that they have been provisioned correctly.
1. Use Central Administration to create a top-level site collection in the finance.contoso.com web
application
2. Use Windows PowerShell to create a host named site collection in the finance.contoso.com web
application
3. Use Windows PowerShell to create a host-named site collection with multiple URLs in the sales web
application.
4. Test the new site collections
Task 1: Use Central Administration to create a top-level site collection in the

finance.contoso.com web application
Use the Central Administration website to create a new top-level site collection in the
finance.contoso.com web application with the following properties.
Title
Finance Extranet
URL
http://finance.contoso.com
Template
Team site
Task 2: Use Windows PowerShell to create a host named site collection in the
Use the New-SPSite cmdlets in Windows PowerShell to create a new host named site collection in
the finance.contoso.com web application with the following properties.
Property
Setting
Title
Finance Intranet
URL
http://finance
Template
Team site (STS#0)
Task 3: Use Windows PowerShell to create a host-named site collection with multiple
URLs in the sales web application.
Use the New-SPSite cmdlets in Windows PowerShell to create a new host named site collection in
the sales.local web application with the following properties.
Property
Title
Sales
URL
http://sales.contoso.com
Template
Team site (STS#0)
Use the Set-SPSiteUrl cmdlet to add the URL http://sales to the site collection you created in the
previous step. You should specify that the additional URL is in the Intranet zone.
Task 4: Test the new site collections
Setting
In Internet Explorer, browse to the http://finance.contoso.com site. Verify that the browser displays
the Finance Extranet site.
On a new tab, browse to the http://finance site. Verify that the browser displays the Finance
Intranet site.
On a new tab, browse to the http://sales.contoso.com site. Verify that the browser displays the
Sales site.
On a new tab, browse to the http://sales site. Verify that the browser displays the Sales site, and that
this is the same site as the http://sales.contoso.com site.
Results: After completing this exercise, you should have created site collections by using the Central
Administration website, and created host-named site collections by using Windows PowerShell.
Exercise 2: Creating Site Collections in New Content Databases

Scenario
In this exercise, you will use Windows PowerShell to create new content databases. You will then use
Windows PowerShell to create new site collections that use the new content databases. You will then test
the site collections to ensure they have been provisioned correctly.
1. Use Windows PowerShell to create new content databases
2. Use Windows PowerShell to create new site collections
3. Test the new site collections
Task 1: Use Windows PowerShell to create new content databases
Use the New-SPContentDatabase cmdlet to create a new content database named

WSS_Content_UK, associated with the finance.contoso.com web application.
Use the New-SPContentDatabase cmdlet to create a new content database named

WSS_Content_USA, associated with the finance.contoso.com web application.
Task 2: Use Windows PowerShell to create new site collections
Use the New-SPSite cmdlet to create a new site collection with the following properties.
URL
http://finance.contoso.com/country/UK
Title
UK
Site template
Team site (STS#0)
Site collection administrator
Content database
WSS_Content_UK
Use the New-SPSite cmdlet to create a new site collection with the following properties.
URL
http://finance.contoso.com/country/USA
Title
USA
Site template
Team site (STS#0)
Site collection administrator
Content database
WSS_Content_USA
In Internet Explorer, browse to the http://finance.contoso.com/country/UK site. Verify that the

browser displays the UK site.
In a new tab, browse to the http://finance.contoso.com/country/USA site. Verify that the browser
displays the USA site.
Results: After completing this exercise, you should have used Windows PowerShell to create new content
databases and new site collections that use the new content databases.
Exercise 3: Creating a Warm-up Script

Scenario
In this exercise, you will test the response time of SharePoint sites, after the application pools have been
recycled. You will repeat this test to verify that the site load time is significantly longer on the first load
after an application pool recycles.
You will then create a warm-up script for the SharePoint site. Finally, you will test your warm-up scripts by
running the script after recycling the application pools. You will verify that after running the warm-up
script, the response time is significantly faster than without a warm-up script.
1. Test the response time of your SharePoint site after an application pool is recycled
2. Use Windows PowerShell to create a warm-up script for the finance.contoso.com web application
3. Test the warm-up script.
Task 1: Test the response time of your SharePoint site after an application pool is
recycled
Restart IIS.
Browse to the http://finance site and time how long it takes for the page to finish loading.
After the page finishes loading, close Internet Explorer.
Open Internet Explorer and browse to http://finance, again time how long it takes for the page to
load. Notice that the page loads significantly faster than the first time you browsed to this page.
Task 2: Use Windows PowerShell to create a warm-up script for the

Use Notepad to create a new Windows PowerShell script named WarmUp.ps1.
Add code to the script that instantiates a variable named $wc by creating a new instance of the
System.Net.WebClient class.
Add code to the script that sets the Credentials property of the $wc object by using the default
credentials from the credential cache (System.Net.CredentialCache).
Add code that uses the DownloadString method of the $wc object to download the home page of
the internal finance site (http://finance).
Save the file and close Notepad.
Note: The warm-up script that you created in this task only warms up a single site collection. You
must hard code each site collection in the script. In a production environment, you could expand this
script to automatically enumerate SharePoint sites and warm-up each of them. You can find sample
warm-up scripts that perform this functionality on the Internet.
Task 3: Test the warm-up script.
Restart IIS.
Browse to the http://finance site and time how long it takes for the page to finish loading.
After the page finishes loading, close Internet Explorer.
Restart IIS again.
Use Windows PowerShell to run the WarmUp.ps1 script that you created in the previous task.
Browse to the http://finance site and again time how long it takes for the page to finish loading.
Verify that the page loads significantly faster after running the warm-up script.
Note: In this task, you ran the warm-up script manually. In a production environment, you could
automate this script to run after your application pools recycle or in response to some other trigger (for
example, if the server restarts). This would help to ensure that your SharePoint site remains responsive to
your users without requiring manual intervention each time a server restarts or an application pool
recycles.
Results: After completing this exercise, you should have created a warm-up script for you SharePoint
sites.
In this module, you have learned about the key concepts and skills related to the logical architecture of
SharePoint, including web applications, site collections, sites, and content databases. You have learned
how to create and configure web applications and how to create and configure site collections.
Review Question(s)
Test Your Knowledge
Question
What is the highest level component in the logical structure of a SharePoint 2013 farm?
Site collection
Web application
Website
Folder
Site
Test Your Knowledge
Question
Which web application configuration feature has been deprecated in SharePoint 2013?
Managed paths
Host named site collections
Host headers
Alternate Access Mapping
Self-Service Site Creation
Test Your Knowledge

Question
Which template category do the Community Portal, Document Center, and My Site
Host templates belong to?
Collaboration
Custom
Enterprise
Publishing

7-1
Module 7
Planning and Configuring Service Applications
Contents:
Module Overview
7-1
Lesson 1: Introduction to Service Application Architecture
7-2
Lesson 2: Creating and Configuring Service Applications
7-11
7-19
7-30
Module Overview
Service applications were introduced in Microsoft SharePoint Server 2010, replacing the Shared Service
Provider architecture of Microsoft Office SharePoint Server 2007. Service applications provide a flexible
design for delivering services, such as Managed Metadata or PerformancePoint, to users who need them.
Microsoft SharePoint Server 2013 includes more than 20 services, some of which are new to this version,
whereas others are enhanced. In planning and configuring service applications, it is important that you
understand the dependencies, resource usage, and business requirements for each.
This module reviews the basic service application architecture, the essentials of planning your service
application deployment, and the configuration of your service applications. This module does not discuss
sharing, or federation, of service applications. This is covered in more detail in course 20332B: Advanced
Solutions of Microsoft SharePoint Server 2013.
Objectives
Explain the key components and topologies for SharePoint Server 2013 service application
architecture.
Describe how to provision and manage SharePoint 2013 service applications.
Lesson 1
Introduction to Service Application Architecture
7-2
The service application architecture was introduced in Microsoft SharePoint Server 2010, replacing the
Shared Service Provider (SSP) model of Microsoft Office SharePoint Server 2007. The architecture remains
consistent in SharePoint 2013, with the addition of new service applications.
The advantage of service applications over the SSP is that services are more granular and can be deployed
only to web applications that require the functionality that individual services offer. This offers greater
design flexibility for the management of resources and functionality.
In this lesson, you will see how service applications are structured and some of the topology options
available when you design you farm structure.
Lesson Objectives
Describe the service application architecture.
List the core service applications and their functions.
Describe the function of service application instances and service application dependencies.
Describe some of the key options for service application topology design.
Explain how to map business requirements to service application design.
Overview of Service Application Architecture

Service applications provide specific functionality
to users in SharePoint 2013. This includes access to
application functionality with Microsoft Excel 2013,
Microsoft Visio 2013, or underlying services such
as the Managed Metadata Service or the Business
Connectivity Services (BCS). The framework of the
service application architecture in SharePoint 2013
is designed so architects can select only the
services that are required to deliver a business
solution.
From a basic, management viewpoint, 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.
One or more physical instancesthe service process running on a physical server.
The structure of service provisioning is a little more complex. A service application is a logical term for
facilities offered in SharePoint 2013 to deliver functionality to users. It is made up of the following
elements:
Service instance. The service instance is the binaries that implement the required functionality. You
can see the service instances that are running on a server from the Services on Server page in Central
7-3
Administration. The list of services shown on this page includes underlying services, such as the
PerformancePoint Server and Excel Calculation Service, which are clearly recognizable as being
related to the SharePoint service applications Excel Service Application and PerformancePoint Service
Application. These provide the functionality that is configured for users in the service applications. On
the Services on Server page, there are also services that you may not recognize or even think of as a
service, such as the Lotus Notes Connector and Central Administration.
Service Machine instance. This is the machine(s) on the farm that runs the service. Not all services have
multiple machine instances and can only be started on one machine on a farm. For services that can
have multiple machine instances, software, round-robin load balancing is provisioned.
Service application endpoint. This is a WCF (Windows Communication Foundation) or ASMX (ASP.NET
Web Services Source) file that is exposed for communication with the service application.
Service application. This is the service that you can configure on the Manage Service Applications
page. You can create multiple instances of a service application. These are configured either through
the Central Administration UI or Windows PowerShell and are global to a farm.
Service connection or service application proxy. This provides the connection between the service and
the web application that consumes the service.
The services are used by a service consumer, which is a term designed to include web applications, Web
Parts, and other clients that may consume services.
For a service application to talk to a specific web application, it must use a service application connection
(proxy). A proxy is created automatically when you create a new service application. You can group
multiple proxies together, which is then referred to as a service application connection group (proxy
group). When you create a web application, you specify the service app proxy group ("default" by default).
The majority of service applications have one or more associated databases. 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. You
should be aware of the potential size to which these databases can grow.
The service application architecture runs across the SharePoint 2013 and SharePoint Online SKUs,
although 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 2013 architects. You can implement
multiple instances of a service application for resilience, performance, or security.
Service Application Functions

There are more than 20 service applications
shipped with SharePoint 2013, and their
functionality is documented in detail across the
Internet. This topic examines some of the more
commonly configured service applications and
reviews those that are new to SharePoint 2013.
Note: You can find a full list and description
of the SharePoint 2013 service applications in the
Services in SharePoint Server 2013 Visio diagram at
Commonly Configured Enterprise Service Applications
7-4
There are some service applications that just about every SharePoint 2013 administrator will configure at
least once. The reason for this is twofoldthey either offer functionality that is popular with business
users, or other services applications that are dependent on functionality they offer.
The service applications that are popular with business users typically include:
Excel Services. This service application provides the ability to publish Excel 2013 workbooks on a
SharePoint 2013 server. It comprises Excel Calculation Services, the Excel Web Access Web Part, and
Excel Web Services for programmatic access.
Search service. This service application provides enterprise search functionality across your
environment. Search has been reengineered to include FAST functionality. FAST Search has been
deprecated in SharePoint 2013.
PerformancePoint Services. This service application provides tools to develop UI options, such as
dashboards, scorecards, and key performance indicators, to help monitor and analyze business
performance.
Visio Services. This service provides the ability for users to render a Visio diagram in a web browser.
The content can also be refreshed and recalculated for diagrams hosted on s SharePoint site.
Services that offer supporting functionality, on which other service applications often depend, include:
Business Connectivity Services. Business Connectivity Services (BCS) provides the access to external
systems data so that it can be used in SharePoint 2013 applications. Several service applications are
closely associated with BCS, such as User Profile Services, because it provides access to user
information held on external systems.
Managed Metadata Service. The Managed Metadata Service (MMS) provides the ability to use
metadata features, such as managed metadata, term sets, and content types across web applications
and site collections.
Secure Store Service. This service provides a database that is used to store authentication credentials.
It is used by other service applications to provide external data access, including Excel Services and
PerformancePoint Services.
State Service. This service provides temporary storage for user session data for SharePoint Server
applications. It is a dependency for other services applications, including Visio Graphics Services and
PerformancePoint Services. The State Service can only be configured through Windows PowerShell.
User Profile Service. This service provides the ability to create and administer user profiles that can be
accessed from multiple sites and farms.
New service applications

There are three notable new service applications in SharePoint 2013:
App Management Service. This service application provides administrators the ability to manage the
new SharePoint apps that are available with SharePoint 2013. SharePoint Apps are described more
fully in course 20332A: Advanced Solutions of Microsoft SharePoint Server 2013. Apps can be
purchased from an external vendor or developed internal to an organization. The App Management
Service checks user access permissions and licensing for apps usage.
Translation Service. This service application connects to the Microsoft Bing translation service to
provide automatic language translation, so that content from one site can be automatically translated
into another language. This is closely linked to the variations functionality offered in SharePoint 2013,
7-5
which provides administrators the ability to deliver duplicate site environments for use in different
languages.
Work Management Service. This service application enables users to synchronize tasks between a
range of Microsoft environments, including Microsoft Exchange and Microsoft Project Server.
Deprecated or merged service applications

For administrators familiar with SharePoint 2013, the following service applications have changed:
Web Analytics Service. The functionality of the Web Analytics Service has been incorporated into the
Search service.
Office Web Apps Service. This is now a separate product, rather than a SharePoint service application.
Service Application Workflow

Typically, service applications deliver service
functionality to users. When a user makes a service
request from a browser, the requestsuch as a
keyword searchis sent through the Web Front
End (WFE) server, which may be preceded by a
hardware network load balancer.
The WFE server sends a request to the application
server that serves the service application. The
service application architecture in SharePoint 2013
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 highperformance communications with WCF clients. Generally, NetTcpBinding is the best option for services
operating inside a firewall, such as on an 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 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.
Service Instances and Service Applications Dependencies

You can deploy multiple instances of service
applications across your SharePoint 2013
environment. This flexibility means that you can
design an implementation that makes best use of
resources and deliver the necessary functionality
to users.
Service application instances

There may be several reasons why you need to
deploy multiple instances of the same SharePoint
2013 service application, including:
7-6
Performance. Service applications all use

server resources. For example, Excel Services can use a good deal of server memory, which may
degrade the performance of a server that is also delivering other services.
Capacity. If you have a large number of users who want to consume a service application, it may offer
greater service capacity if you provide multiple instances, thereby benefiting more users, and
avoiding service contention.
Service management. You may find that diverse groups or web applications need to consume specific
versions of a service application. For example, different divisions can use different metadata so you
can deploy multiple instances of the Managed Metadata Service to service these requirements.
Service application dependencies
Not all services are entirely self-contained, so you must review possible service dependencies when you
plan your logical architecture design. However, with the granular framework in SharePoint 2013, it is now
possible to deploy dependent service applications without enabling core service applications. Dependent
service applications will not function as expectedand may not function at allwithout the required
platform services in place.
Some dependencies are more obvious than others, such as that between People Search and the User
Profile Service (UPS). 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.
7-7
The following table shows some common dependencies that will affect your service application planning.
This is not an exhaustive list of dependencies.
Single Farm Service Application Topologies

Even in a single farm design, service applications
can have a major impact on the topology of your
overall solution. This is because users want
functions and services that offer a wide range of
functionality. The breadth of these service
offerings means that you can choose 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. 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 adding service application instances to deal with growth. This may also be an option for
managing spikes in demand or unexpected changes in usage.
Note: You can also develop a topology that is driven by federating service applications, but
this is covered in course 20332A: Advanced Solutions of Microsoft SharePoint Server 2013.
Single Service Application Proxy Group

The example 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 like 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.
7-8
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.
This is almost certainly the most common deployment topology for service applications, although part of
that may be because 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.
Multiple Service Application Proxy Groups in Multiple Application Pools

As you have seen, it is possible to deploy multiple
instances of the same service application; in fact,
this can provide better performance, capacity, or
flexible service provisioning,
The topology on the diagram 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.
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. 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.
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.
Application pools
7-9
You can deploy service applications to different application pools to achieve process isolation. However, if
you want to optimize the performance of your farm, you should deploy service applications to only one
application pool.
To achieve physical isolation for a service application, choose or create a different application pool for the
service application. You should do this only if there is a significant business need for it.
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 on the design.
This will largely be a high-level agreement on
function because supporting services will have
little meaning for most business users. Like with
the logical design, it is essential that you maintain the documentation of your service application for
management and administration purposes.
Identifying business requirements for service applications
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 client applications 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.
Isolated services
After you identify 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
7-10 Planning and Configuring Service Applications
You should identify which, if any, services are critical to your business and a level of performance that is
acceptable to the users. After 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. Implementation of multiple instances of a service application
(on the same server) or multiple service application instances (across multiple servers) will clearly have a
ramification on cost and performance. Farm resources are consumed to support multiple instances of
some service applications, which can affect performance. You need to closely monitor server systems
performance changes when you deploy multiple service instances.
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 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.
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.
Discussion: Mapping Business Requirements to Service Applications

By using the information covered in this lesson,
discuss the following questions with reference to
your own organizations.
Lesson 2
Creating and Configuring Service Applications
7-11
As you have seen, service applications provide flexibility and granularity of service delivery to users. The
administration of service applications may appear to mean more work for farm administrators, but
SharePoint 2013 provides both Central Administration and Windows PowerShell options for performing
service application management tasks, such as creation, control, and configuration.
In addition, you can delegate some of the management tasks. Depending on your organizations size or
business profile, you can delegate the administration of an entire service application or just certain of its
features.
In this lesson, you will see how to create and manage service applications, as well as how to delegate
various aspects of their operation administration.
Lesson Objectives
Describe how to create service applications.
Explain the Central Administration and Windows PowerShell facilities for service application
management.
Describe the permissions required to manage a service application.
List the options for service application administration delegation.
Explain how to manage proxies and proxy groups.
Creating Service Applications

The Farm Configuration Wizard in SharePoint
establishes all default service applications that you
need. This wizard is particularly useful for
development or test environment because it
allows you to get everything up and running
quickly, although you may deploy service
applications that your organization does not use.
Manual configuration of service groups is also

possible through Central Administration or
Windows PowerShell. Manual configuration is
good for all production farms, where you must
plan and design the service applications more
thoroughly. You can assign different permissions to each instance of a service application so that you have
distributed management of the SharePoint service application model.
Central Administration UI
Before you start, you must ensure that the user account that you are using is a member of the Farm
Administrators group for the farm for which you want to create the service application. To configure a
service application using Central Administration:
1.
On the Central Administration Home page, in the Application Management section, click Manage
service applications.
2.
On the Manage Service Applications page, on the ribbon, click New, and then click
<Service_Application_Name>.
Depending on the service application that you want to create, there will then be configuration options
that you need to complete.
Windows PowerShell
Windows PowerShell provides cmdlets to create service applications. Here are some examples:
New-SPAccessServiceApplication. This cmdlet creates a new Microsoft Access service application.
New-SPMetadataServiceApplication. This cmdlet creates a new managed metadata service

application.
New-SPMetadataServiceApplicationProxy. This cmdlet creates a new connection to a managed

metadata service application.
Note: There is more detailed explanation of the use of service application proxies and
proxy group later in this lesson.
Note: The reference for service application cmdlets in SharePoint 2013 is available at
Service application provisioning
You can deploy service applications to different application pools to achieve process isolation. However, if
you want to optimize the performance of your farm, you should deploy service applications to only one
application pool. To achieve physical isolation for a service application, choose or create a different
application pool for the service application. You should do this only if there is a significant business need
for it. You should not exceed more than 10 application pools per web server.
Note: Additional information about monitoring application pool resources is included in
Module 14: Monitoring and Maintaining a SharePoint 2013 Environment.
Starting and Stopping Service Instances

The flexible SharePoint 2013 architecture for
service applications enables you to start and stop
individual services. This enables you to make
changes to the service functionality by
reconfiguring settings, or withdrawing the
functionality altogether. This management
flexibility also makes it easier to scale out your
farm, by moving services to additional physical
servers, in a case where you want to improve
performance by migrating a service to a new
server. Whatever the reason, it is straightforward
to both stop and start services. You can perform
most of these actions through the SharePoint Central Administration user interface (UI), and you can
perform all of them through Windows PowerShell.
Central Administration management
To start a service from Central Administration, ensure that you are logged on as a user who is a member
of the Farm Administrators SharePoint group and use the following procedure:
1.
On the SharePoint Central Administration website, click System Settings.
2.
On the System Settings page, in the Servers section, click Manage services on server. (To change
the server on which you want to start a service, on the Server menu, click Change Server, and then
click the required server name. By default, only configurable services are displayed. To view all
services, on the View menu, click All.)
3.
In the Action column of the service, click Start.
4.
Click OK to start the service.
To stop a service, use the same procedure, except click Stop instead of Start.
Windows PowerShell
Before you start, you must ensure that your user login has the following memberships:
securityadmin fixed server role on the SQL Server instance
db_owner fixed database role on all databases that are to be updated
Administrators group on the server on which you are running the Windows PowerShell cmdlets
The procedure shown here is based on Windows Server 2012. You may find that Windows PowerShell
initiation may be different for other Windows Server releases:
1.
Start the SharePoint 2013 Management Shell.
2.
At the Windows PowerShell command prompt, type the following command.

Start-SPServiceInstance -Identity <ServiceGUID>
Note: If you do not know the ServiceGUID, you can present a list of all the services GUIDs
by running the Windows PowerShell cmdlet Get-SPServiceInstance.
To stop a service application with Windows PowerShell, you should follow the same procedure, except run
the following cmdlet instead.
Stop-SPServiceInstance -Identity <ServiceGUID>
Service Accounts and Permissions

Many services need to have access to files on
SharePoint 2013 databases or external data
sources. For example, the Search service crawler
will need to have read access or read permissions
to content held in a variety of locations, such as
file shares or external databases. Others, such as
the State Service, do not need a service account,
because it only provides temporary session data
storage. In order to access these files, the service
application needs to have an associated user
accountthis user is the identity of the
application pool that runs the service application.
This service user (or service user account) may need to have specific roles, group memberships, or
permissions.
It is recommended that you use the principle of least-privilege when creating service accounts. This means
that you should give the service account no greater access permissions than are necessary to complete
their task. It is not uncommon for small organizations to run everything as an administrator. This is done
mostly to avoid access errors. However, it is poor practice to have an administrator account in a service
account role. Although it does obviate access errors, it also means that any user employing a service that
uses that account may unwittingly have unrestricted access to data.
The following table describes the accounts that are used to set up and configure a service application.
Plan the application pool and proxy group for each service application that you plan to implement, but
remember that you should have no more than ten application pools per server.
Service Name
Access Services
Business Data
Connectivity service
Account Function
Required Roles and

Permissions
Used as the identity for the

service application endpoint
application pool. The application
pool can be used to host multiple
service application endpoints.
Member of the Farm

Administrators group.
Used as the identity for the

service endpoint application pool.
The application pool can be used
to host multiple service
application endpoints.
Domain user account.
Usage and Health Data

Collection Service
User Profile Service
Visio Graphics Service
Word Automation
services
Excel Services
Managed Metadata
Service
PerformancePoint
Service
Search Service
Service Name
Account Function
Required Roles and

Permissions
This account is used as the

identity for the service application
endpoint application pool. The
SharePoint Products
Configuration Wizard
automatically creates the
application pool.
Must be a member of the

Farm Administrators group.
Excel Services
Used with workbooks to refresh

data. This service account is
required when workbook
connections specify "None" for
authentication, or when nonWindows credentials are used to
refresh data.
PerformancePoint Service
Used for authenticating with data

sources.
Visio Graphics Service
Used with documents to refresh

data. It is required when
connecting to data sources that
are external to SharePoint Server
2013.
Member of the Farm

Search
The default account for crawling

content. A Search service
application administrator can
create crawl rules to specify other
accounts to crawl specific
content.
Must have:
Read Access to the content
being crawled.
Full Read permissions granted
explicitly to content outside
the local farm.
(Full Read permissions are
automatically configured for
content databases in the local
farm.)
Search
The Windows service account for

the SharePoint Server Search
service.
User Profile Synchronization

Service
Used as the account for the User

Profile Synchronization Service.
Member in the Farm

Log on Locally permission on
the computer running the
User Profile Synchronization
Service instance.
Local Administrator
permissions on the server
running the User Profile
Synchronization Service
instance.
User Profile Service
Used to perform synchronization
Replicating Directory Changes
Security Token Service

Application Discovery
and Load Balancer
Service
Service Name
Account Function
Required Roles and

Permissions
with the remote directory service.

(Only one account for each
synchronization connection.)
permissions on the domains

being synchronized.
Replicating Directory Changes
permissions on the
configuration partition of the
domains being synchronized if
the NetBIOS and fully
qualified domain name
(FQDN) names do not match.
App management
Permits installation of SharePoint

apps from the SharePoint Store or
App Catalog.
Member of the Farm

Administrators group
PerformancePoint Service
Converts Microsoft PowerPoint

presentations to other formats.
Member of the Farm

Machine Translation Service
Performs automated machine

translation.
Member of the Farm

Access Services in SharePoint

Server 2013
Views and interacts with Access

2010 databases in a browser.
Member of the Farm

Workflow Management
Provides task aggregation across

work management systems.
Member of the Farm

You must create additional application pool identity accounts if you create additional application pools.
Worker processes that service the application pool will use the application pool account as their process
identity.
Service Application Delegated Administration

For a large organization, it can become unwieldy
to have a single-service application administrator.
SharePoint 2013 provides the ability to delegate
service application administration to other users.
This means that the farm administrator does not
become a bottleneck for service management,
because delegated administrators can deal with
minor change requests.
Service application administrators

Farm administrators always have rights to manage
all service applications. These rights cannot be
removed.
Service application administrators are appointed by members of the Farm Administrators group. The
administrators of a service application can configure settings for a specific service application in a farm.
However, these administrators cannot create service applications, access any other service applications in
the farm, or perform any farm-level operations, including topology changes. For example, the service
application administrator for a Search service application in a farm can configure settings for that Search
service application only.
Delegating administration of a service application

To delegate service application administration, use the following procedure:
7-17
1.
In Central Administration Quick Launch, click Application Management, and then, in the Service
Applications section, click Manage Service Applications.
2.
Select the row of the service application for which you want to delegate administrative duties.
Do not click the name of a service application. Most service application names are links to the service
applications management application.
3.
On the ribbon, click Administrators.
Service application feature administrators
A feature administrator is associated with a specific feature or features of a service application. These
administrators can manage a subset of service application settings but not the entire service application.
For example, a feature administrator might manage features of the User Profile service application. A
feature administrator can perform all administrative tasks that are related to the delegated feature or
features. A feature administrator cannot manage other features, service applications, or settings that are
contained in Central Administration. For the User Profile Service, you can delegate the following features
administration:
Manage Profiles
Manage Audiences
Manage Permissions
Retrieve People Data for Search Crawlers
Manage Social Data
Service Application Proxies and Proxy Groups

A service application is made up 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.
Service application proxy groups
SharePoint 2013 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
proxy group 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 the services in a proxy group; you can configure this
through the Configure Service Application Associations page on the SharePoint Central Administration
site.

Scenario
The IT team at Contoso has provisioned two SharePoint web applications, sharepoint.contoso.com and
sales.contoso.com. The sharepoint.contoso.com site will provide a general purpose intranet for corporate
communications and project management, and will be managed by the operations team. The
sales.contoso.com site will provide more specialized support for geographically dispersed field sales
teams.
Your role is to provision some initial service applications for these intranet portals. Both the operations
team and the sales team want the ability to convert Microsoft Word documents and Microsoft PowerPoint
presentations into webpages, so that team members can quickly and easily browse information, resources,
and procedural guidelines. Both teams also require the ability to create managed metadata term sets to
help them structure their information architectures. However, the sales team wants a distinct Managed
Metadata Service application so that they can administer and manage their term store independently.
Your first task will be to create and configure the required service applications and service application
proxies. Next, you will create two proxy groups to manage the service applications that are available to
each web application. Finally, you will assign a proxy group to each web application and verify that the
service applications behave as expected.
Objectives
Provision a Managed Metadata Service application by using Central Administration.
Provision a Managed Metadata Service application by using Windows PowerShell.
Configure services and service applications for document conversion.
Configure service application proxies and proxy groups.
Password: Pa$$w0rd
Exercise 1: Provisioning a Managed Metadata Service Application with

Central Administration
Scenario
In this exercise, you will provision a managed metadata service application for use by the operations team.
You will provision the service by using Central Administration.
You will start the necessary services and then you will create a new user account that you will register as a
managed service account. You will use this account when you create the managed metadata service
application instance.
Finally, you will verify that the service has been deployed successfully by viewing the default taxonomy in
the term store.
1. Create a service account to run the Managed Metadata Service
2. Configure the State Service
3. Register the service account as a SharePoint managed account

4. Start the Managed Metadata Web Service service
5. Create a new Managed Metadata Service application instance
6. Verify that the service application was provisioned successfully and add terms to the term store
Task 1: Create a service account to run the Managed Metadata Service
Log on to the 20331B-NYC-DC-07 virtual machine as [email protected] with the

password Pa$$w0rd.

Property
Setting
Full name
SharePoint General MMS
UPN logon
[email protected]
contoso\SPGeneralMMS
Password
Pa$$w0rd
Selected
Selected
Task 2: Configure the State Service
Log on to the 20331B-NYC-SP-07 virtual machine as [email protected] with the

password Pa$$w0rd.
In Windows PowerShell, use the New-SPStateServiceApplication cmdlet to create a new State

service application named Contoso State Service.
Use the New-SPStateServiceDatabase cmdlet to create a new database for the Contoso State
Service application.
Use the New-SPStateServiceApplicationProxy cmdlet to create a new service application proxy for
the Contoso State Service application. Ensure that the proxy is added to the default proxy group.
Wait for ten minutes before you proceed to the next task.
Note: The state service can take up to ten minutes to provision. If you provision the
managed metadata service before the state service is provisioned some default terms will be
missing from the term set.
Task 3: Register the service account as a SharePoint managed account
Navigate to the Managed Accounts page.
Register the contoso\SPGeneralMMS account you created in the previous tasks as a managed
account.
Task 4: Start the Managed Metadata Web Service service
Navigate to the Services on Server page on the Central Administration website.
Start the Managed Metadata Web Service service.
Task 5: Create a new Managed Metadata Service application instance
On a new tab, browse to the http://sharepoint.contoso.com site collection, activate the

ContentTypeSyndicationHub site collection Feature, and then close the tab.
On the Central Administration website, navigate to the Manage Service Applications page.
Create a new Managed Metadata Service with the following settings.

Property
Setting
Name
Contoso General Managed Metadata
Database name
ContosoGeneralMMSDB
ContosoGeneralMMSAppPool
Application pool security account
CONTOSO\SPGeneralMMS
Content type hub
Task 6: Verify that the service application was provisioned successfully and add terms
to the term store
Navigate to the Term Store Management page.
Verify that the default term store is displayed.
Note: If the page renders incorrectly, or you do not see the People and Search Dictionaries term
sets, then reload the page.
Under the People group, add the term Marketing to the Department term set
Under the People group, add the term Sales to the Department term set.
Results: After completing this exercise, you should have enabled, provisioned, and configured a Managed
Metadata Service application by using Central Administration.

Windows PowerShell
Scenario
In this exercise, you will provision an additional managed metadata service application for the sales team.
You will provision the service application by using Windows PowerShell.
You will create a new user account that you will use Windows PowerShell to register as a managed service
account. You will use this account when you create the managed metadata service application instance.
Finally, you will verify that the service has been deployed successfully by viewing the default taxonomy in
the term store.
1. Create a service account to run the Managed Metadata Service instance
Task 1: Create a service account to run the Managed Metadata Service instance
Open an Active Directory Module for Windows PowerShell scripting window.
Use the New-ADUser cmdlet to create a new user with the following properties.
Property
Setting
Full name
SharePoint Sales MMS
User principal name
[email protected]
SAM account name
contoso\SPSalesMMS
Note: You will set additional settings on this user account in this task. You should consider creating a
variable to store the user name of the new user account for easy reference in the rest of this task.
Use the Set-ADAccountPassword cmdlet to set the password of the new account to Passw0rd!.
Note: You must pass a SecureString object to the Set-ADAccountPassword cmdlet. You can create
a SecureString object by using the ConvertTo-SecureString cmdlet, specifying the password in the
String parameter, and specifying the AsPlainText parameter to indicate that you intend to convert a
plain text value.
Converting from plain text can pose a security risk because the system is unable to protect the input
string. You must specify the Force parameter with the AsPlainText parameter to indicate that you
understand this risk.
Use the Enable-ADAccount cmdlet to enable the new account.
Use the Set-ADAccountControl cmdlet to set the following account properties on the new user.
Property
Setting
True
Cannot change password
True
Use the Set-ADUser cmdlet to set the following account properties on the new user.
Property
Setting
Change password at logon
False
Switch to the 20331B-NYC-SP-07 virtual machine. If you are not already logged on, log on to the
20331B-NYC-SP-07 virtual machine as [email protected] with password Pa$$w0rd.
Use the New-SPManagedAccount cmdlet to register the SPSalesMMS account as a SharePoint

managed account.
Use the Get-SPManagedAccount cmdlet to verify that the SPSalesMMS account is now registered.
Use the New-SPServiceApplicationPool cmdlet to create a new application pool for the service
application with the following properties.
Property
Setting
Name
ContosoSalesMMSAppPool
Account
[email protected]
Note: Throughout this task, you will need to reference objects you create in previous steps. Saving a
reference to each object you create in a variable will help you to complete this task.
Use the New-SPMetadataServiceApplication cmdlet to create a Managed Metadata Service

application instance with the following properties.
Property
Setting
Name
Contoso Sales Managed Metadata
Application pool
ContosoSalesMMSAppPool
Database name
ContosoSalesMMS
Hub uri
http://sales.contoso.com
Use the New-SPMetadataServiceApplicationProxy cmdlet to create a service application proxy for

the new Managed Metadata Service application instance with the following properties.
Property
Setting
Name
Service application
Added to default proxy group
True
Verify that both (general and sales) Managed Metadata Service service instances now appear on the
Manage Service Applications page in Central Administration.
Results: After completing this exercise, you should have enabled, provisioned, and configured a managed
metadata service application by using Windows PowerShell.
Exercise 3: Configuring Service Applications for Document Conversions

Scenario
In this exercise, you will configure service applications to enable conversion of Word and PowerPoint
documents.
You will use Windows PowerShell to create the necessary service accounts and then create service
instances with associated proxies, and then use Central Administration to verify that the services were
created properly.
Finally, you will use Central Administration to configure document conversions for the
sharepoint.contoso.com and sales.contoso.com sites.
1. Start the required services
2. Create a service account to run the Word Automation Services service application
4. Create a new Word Automation Services application instance
5. Create a service account to run the PowerPoint Conversion Services service application
7. Create a new PowerPoint Conversion Services application instance
8. Enable document conversions on the sharepoint.contoso.com and sales.contoso.com web applications
Task 1: Start the required services
Note: In addition to starting these tasks by using the Central Administration website, you could
alternatively choose to start these services by using Windows PowerShell commands. You can use the
Get-SPServiceInstance cmdlet to return a list of available services and the Start-SPServiceInstance
cmdlet to start a service.
The following command demonstrates how to use Windows PowerShell to start the Word Automation
Services service:
Get-SPServiceInstance | where {$_.TypeName -eq "Word Automation Services"} | Start-SPServiceInstance
Start the Word Automation Services service.
Start the PowerPoint Conversion Service service.
Start the Document Conversions Load Balancer Service service.
Start the Document Conversions Launcher Service service. Specify the SharePoint server as the load
balancer server, and use the default port number.
Task 2: Create a service account to run the Word Automation Services service
application
Property
Setting
Full name
SharePoint Word Automation
User principal name
[email protected]
SAM account name
contoso\SPWordAutomation
Property
Setting
True
True
Property
Setting
False
Switch to the 20331B-NYC-SP-07 virtual machine.
Use the New-SPManagedAccount cmdlet to register the SPWordAutomation account as a

SharePoint managed account.
Use the Get-SPManagedAccount cmdlet to verify that the SPWordAutomation account is now
registered.
Task 4: Create a new Word Automation Services application instance
Property
Setting
Name
ContosoWordAutomationAppPool
Account
[email protected]
Use the New-SPWordConversionServiceApplication cmdlet to create a Word Automation Services

application instance with the following properties.
Property
Setting
Name
Contoso Word Automation Service
Application pool
ContosoWordAutomationAppPool
Database name
ContosoWordAutomation
Note: When you create an instance of the Word Automation Services service, a proxy connection is
generated automatically, so you do not need to create one manually.
Verify that the Word Automation Services service and an associated proxy connection now appear on
the Manage Service Applications page in Central Administration.
Task 5: Create a service account to run the PowerPoint Conversion Services service
application
Property
Setting
Full name
SharePoint PowerPoint Conversion
User principal name
[email protected]
SAM account name
contoso\SPPowerPointConv
Property
Setting
True
True
Property
Setting
False
Use the New-SPManagedAccount cmdlet to register the SPPowerPointConv account as a

SharePoint managed account.
Use the Get-SPManagedAccount cmdlet to verify that the SPPowerPointConv account is now
registered.
Task 7: Create a new PowerPoint Conversion Services application instance
Property
Setting
Name
ContosoPowerPointConvAppPool
Account
[email protected]
Use the New-SPPowerPointConversionServiceApplication cmdlet to create a PowerPoint

Conversion Services application instance with the following properties.
Property
Name
Contoso PowerPoint Conversion
Application pool
ContosoPowerPointConversionAppPool
Use the New-SPPowerPointConversionServiceApplicationProxy cmdlet to create a service

application proxy for the new PowerPoint Conversion Service application instance with the following
properties.
Property
Setting
Setting
Name
Contoso PowerPoint Conversion Proxy
Service application
Contoso PowerPoint Conversion
Verify that the PowerPoint Conversion Service Application service and an associated proxy connection
now appear on the Manage Service Applications page in Central Administration.
Task 8: Enable document conversions on the sharepoint.contoso.com and

sales.contoso.com web applications
On the Central Administration website, navigate to the General Application Settings page.
Enable document conversions for the http://sharepoint.contoso.com web application by specifying

the SharePoint server as the load balancer server.
Enable document conversions for the http://sales.contoso.com web application by specifying the
SharePoint server as the load balancer server.
Results: After completing this exercise, you should have provisioned document conversion service
applications by using Windows PowerShell and configured those services by using the SharePoint 2013
Central Administration website.
Exercise 4: Configuring Service Application Proxy Groups

Scenario
In this exercise, you will create two new application proxy groups. You will add service application proxies
to each of these proxy groups and then associate these proxy groups with web applications.
You will test the associations by verifying that the managed metadata service is different for each of the
web applications (the sales.contoso.com web application will be associated with the Contoso Sales
Managed Metadata service application instance, and the sharepoint.contoso.com web application will be
associated with the Contoso General Managed Metadata service application instance).
Finally, you will test document conversions by converting a Word document into a webpage.
1. Create a new service application proxy group named General
2. Create a new service application proxy group named Sales
3. Map proxy groups to web applications
4. Verify managed metadata term set associations
5. Verify document conversion configuration
Task 1: Create a new service application proxy group named General
Use the New-SPServiceApplicationProxyGroup cmdlet to create a new service application proxy

group named General.
Use the Get-SPServiceApplicationProxy cmdlet to view a list of available service application proxies.
Use the Add-SPServiceApplicationProxyGroupMember cmdlet to add the Contoso General

Managed Metadata service application proxy to the General proxy group.
Note: You can use the where filter to select an individual service application proxy when you use the
Get-SPServiceApplicationProxy cmdlet. The following code example shows how to use the where filter
with the like operator to retrieve a single proxy without needing to type the full name of the proxy:
$proxy = Get-SPServiceApplicationProxy | where { $_.DisplayName -like "Contoso General*"}
Use the Add-SPServiceApplicationProxyGroupMember cmdlet to add the Contoso Word

Automation Service service application proxy to the General proxy group.
Use the Add-SPServiceApplicationProxyGroupMember cmdlet to add the Contoso PowerPoint

Conversion Proxy service application proxy to the General proxy group.
Task 2: Create a new service application proxy group named Sales
Use the New-SPServiceApplicationProxyGroup cmdlet to create a new service application proxy

group named Sales.
Use the Add-SPServiceApplicationProxyGroupMember cmdlet to add the Contoso Sales Managed

Metadata service application proxy to the Sales proxy group.
Use the Add-SPServiceApplicationProxyGroupMember cmdlet to add the Contoso Word

Automation Service service application proxy to the Sales proxy group.
Use the Add-SPServiceApplicationProxyGroupMember cmdlet to add the Contoso PowerPoint

Conversion Proxy service application proxy to the Sales proxy group.
Task 3: Map proxy groups to web applications
Navigate to the Application Management page.
Configure the sharepoint.contoso.com web application to use the General application proxy group.
Configure the sales.contoso.com web application to use the Sales application proxy group.
Task 4: Verify managed metadata term set associations
Navigate to http://sharepoint.contoso.com.
Browse to the Site Columns page, and then briefly view the existing columns.
Click Create to view the Create Column page.
Select the Managed Metadata type, and then under Term Set Settings, verify that Contoso General
Managed Metadata is specified.
Navigate to the http://sales.contoso.com site.
Browse to the Site Columns page, and then briefly view the existing columns.
Click Create to view the Create Column page.
Select the Managed Metadata type, and then under Term Set Settings, verify that Contoso Sales
Managed Metadata is specified.
Task 5: Verify document conversion configuration
Enable the SharePoint Server Publishing Infrastructure site collection feature.
Enable the SharePoint Server Publishing site feature.
Navigate to the Documents document library.
Convert the ConversionTest.docx file to a webpage with the title Annual Report, and then navigate
to the new page. The source document has images which are not converted in this process. This is
expected behavior.
Publish the new page to make it visible to all users.
Results: After completing this exercise, you should have created two proxy groups and associated each of
these with a web application. You should have tested that these associations are working correctly and
you should have demonstrated Word document conversion to a webpage.

Having completed this module, you should now be able to:
Explain the key components and topologies for a SharePoint Server 2013 service application
architecture.
Describe how to provision and manage SharePoint 2013 service applications.
Review Question(s)
Test Your Knowledge
Question
Which of the following enables users to synchronize tasks between a range of Microsoft
environments, including Exchange and Project Server?
Business Connectivity Service
Managed Metadata Service
State Service
Work Management Service
Test Your Knowledge
Question
Which of the following statements describing service application administration is
incorrect?
You can administer all service application functions through the Central
Administration UI.
You can administer all service application functions through Windows PowerShell.
You can delegate service application administration.
You can delegate service application feature administration.
You can create service applications in the Default group through the Central
Administration UI.

8-1
Module 8
Managing Users and Permissions
Contents:
Module Overview
8-1
Lesson 1: Authorization in SharePoint 2013
8-2
8-12
Lesson 2: Managing Access to Content
8-19
8-28
8-34
Module Overview
Many organizations need to store sensitive or confidential information. Microsoft SharePoint Server 2013
includes a complete set of security features, which you can use to help ensure that users with the
appropriate rights and permissions can access the information they need, can modify the data they are
responsible for, but that they cannot view or modify confidential information, or information that is not
intended for them. The SharePoint 2013 security model is highly flexible and adaptable to your
organizations needs.
In this module, you will learn about the various authorization and security features available in SharePoint
2013 to help you maintain a secure SharePoint environment. Specifically, you will be learning about
authorization and permissions in SharePoint 2013, and how to manage access to content in SharePoint
2013.
Objectives
Understand and manage authorization and permissions in SharePoint 2013.
Manage access to content in SharePoint 2013.
Lesson 1
Authorization in SharePoint 2013
8-2
In this lesson, you will learn about core authorization concepts in SharePoint 2013. Specifically, you will
learn how to plan for authorization, and how to manage key authorization elements, such as SharePoint
groups, permission levels, and web application policies.
Lesson Objectives
Understand core authorization concepts in SharePoint 2013.
Plan for authorization in SharePoint 2013.
Manage permissions levels in SharePoint 2013.
Manage SharePoint groups in SharePoint 2013.
Manage web application policies in SharePoint 2013.
Understanding Authorization in SharePoint 2013

In SharePoint 2013, you need an authorization
process to control your users access to SharePoint
objects and content, such as websites, list items,
folders, and documents. Authorization is a method
of granting user access to objects based on factors
such as group membership, role assignment, or
direct permissions.
To grant access to an object, you can either grant
permissions directly to the user, or add the user to
a group and grant the group the permission
required, or you can assign a role to the user and
grant permissions to the role.
The scope of authorization

There will be scenarios in your SharePoint farm where you do not want all your SharePoint sites to be
accessible by all of your users; this allows you to protect confidential information or sensitive
departmental content. Some sites, such as a public-facing corporate website, will require access by all
users. Other sites, such as an intranet portal, will need to be restricted to employees only.
You can grant permissions to users and groups on SharePoint 2013 sites and objects at the following
levels:
Site
List or library
Folder
Item or document
Authorization security principals
Permissions control access to a site and its contents, but you assign permissions to security principals. A
security principal is an object to which you can assign permissions, and in SharePoint 2013 that means
users and groups. If you add a user to a site, the user is the security principal; if you add a group to the
site, the group is the security principal. The best way to control security and reduce the complexity of
security maintenance in SharePoint 2013 is to maintain a relatively small number of security principals per
scope. This can be achieved by using security groups to grant access to large numbers of users. Groups
will be discussed in more detail later in this lesson.
Authorization in SharePoint 2013

The following are examples of methods and features you can use to control access to resources in
SharePoint 2013:
Objects can have permissions assigned directly to them.
Objects can inherit permissions from a parent object, such as a website, folder, or list.
Active Directory domain groups can be used to organize users into groups.
SharePoint groups can be used to organize your users and grant permissions to objects.
User permissions can be used to directly grant granular permissions to objects in a web application.
Permission levels that are collections of individual permissions can be used to grant several
permissions at once.
Permission policies can be used to apply permission levels to objects in a web application.
Web application policies can be used to define broad permission policies on objects.
Anonymous access policies can be used to grant users the permission to view pages or to contribute
anonymously to lists and surveys.
Many of these methods and features will be discussed in more detail later in this module.
Note: Whichever method, or methods, you use to authorize user access to SharePoint
objects in your environment, it is independent of the user authentication mechanism you use
because SharePoint 2013 converts all authenticated users into a SharePoint User object (SPUser).
The Share feature
In SharePoint 2013, sites, documents, and list items now include a prominent Share menu item. This is
designed to make it easier and more intuitive for administrators and users to share their resources with
other users: a user can click Share, select one or more users, and grant the required permissions. However,
this can lead to a proliferation of individual user permissions, which in turn increases the complexity of
security maintenance. Content owners must be mindful of this risk to prevent permissions from becoming
overly complex.
Planning for Authorization in SharePoint 2013

There are two key points to consider when
planning authorization for your SharePoint 2013
farm:
8-4
Permission granularity. How granular do you

need your site and site content permissions to
be? Do you need to only broadly control
access at the site level, or do you need to
define more specific security restrictions on
individual items such as list, folders, or
documents?
Permission assignment. How will you assign

permissions to your SharePoint groups? When
you assign permissions to SharePoint groups at the site collection level, all sites and site content
inherit those permissions by default. Do you want permission inheritance to occur at all levels, or just
some levels? Are the default permission levels sufficient for your needs, or do you need to customize
your own?
Site collections as security and administration boundaries
Site collections are used to provide a security boundary between one collection of sites and another. They
each have their own collection of SharePoint groups and permission levels.
Site collections are also used to create a boundary for management and administration; each site
collection has its own Site Collection Administrator role, with at least one user in that role. This can be
very useful in large organizations where you need to distribute site collection administration. A site
collection administrator has full control rights for the entire site collection, including the root site, all of
the sites under the root, and all lists and libraries in the site collection.
Planning SharePoint site permissions

Permissions allow a user to perform certain actions on a SharePoint site. It is very important when
planning authorization for SharePoint 2013 that you find the appropriate balance between simplified
administration and more complex granular security measures. If you overuse fine-grained permissions,
your cost of administration will increase; if you oversimplify access permissions, you may not have the
appropriate level of security in place.
You should consider the following general guidelines when planning permissions for your site:
Apply least-privilege principle. Your users should only have the permissions they need in order to
perform their job or specific task.
Use standard SharePoint groups. You should add your users to the standard SharePoint groups that
have the least permissions, unless they need more. Use the SharePoint groups that have greater
permissions sparingly.
Limit the number of users in the Owners group. You should only add users to this group if you trust
them to change site elements such as the structure, settings, appearance, and permissions.
Use permission levels instead of custom permissions where possible. Generally, it is far easier to control
access using the predefined permission levels than it is to use custom permissions.
Permission levels
Permission levels are combinations of individual permissions that allow users to perform a set of related
tasks. For example, the Read permission level consists of 11 individual permissions spread over List
Permissions and Site Permissions that include View Items, Open Items, Create Alerts, View Application
8-5
Pages, Use Self-Service Site Creation, and View Pages permissions. All of these individual permissions
make up the permissions required by a user to view pages, documents, and items and to use self-service
site creation in a SharePoint site.
Note: You can include individual permissions in more than one permission policy level.
User groups
One of the key issues when planning authorization for SharePoint 2013 is deciding which group types to
use. SharePoint 2013 supports two group types:
AD Domain security groups. These groups are outside the control of SharePoint 2013 itself. Domain
security groups are defined and managed in Active Directory and can be used anywhere within the
scope of the Active Directory directory service.
SharePoint groups. These groups are defined and managed within SharePoint 2013 at the sitecollection level for easy permissions administration. They can only be used within the site collection.
By adding domain security groups to SharePoint groups, you can centralize group and security
management. When you add a security group to a SharePoint group, you remove the need to control
members of the SharePoint group in the future. As users are added or removed from the domain security
group, their membership of the SharePoint group is automatically controlled.
However, there is a drawback to this approach. Because domain security groups are not fully visible in
SharePoint sites, the site does not appear in the users My Sites, and user information lists do not show
individual users until that user has contributed to the site.
Best Practice: It is recommended that for intranet sites that are generally accessed by your
users, you should use security groups because you do not need to be aware of the individual
users accessing the intranet site. However, for collaborative sites, such as Team Sites, you should
add users directly to SharePoint groups. In this scenario, it is more important that you know, and
directly control, exactly who is accessing this type of site.
Managing Permission Levels

You define permission levels at the site collection
level and five of the seven levels can be
customized by users with sufficient permissions.
Default permission levels

The default permission levels include:
Full Control. User has full control. You cannot

customize this permission level.
Design. User can view, add, update, delete,

approve, and customize the layout of site
pages by using the browser or SharePoint
Designer 2013.
Edit. User can add, edit, and delete lists; and can view, add, update, and delete list items and
documents.
Contribute. User can view, add, update, and delete list items and documents.
8-6
Read. User can view pages and list items, and download documents.
Limited Access. User can view specific lists, document libraries, list items, folder, or documents when
given permissions. You cannot customize this permission level.
View Only. User can view pages, list items, and documents.
Note: There are other permission levels, such as Approve, Manage Hierarchy, and
Restricted Read, but they are only visible when you define permission levels for a site that was
created using the Publishing Portal template.
Additional Reading: For more information about permissions that are included in the
default permission levels, see User permissions and permission levels in SharePoint 2013 at
Custom permission levels
There may be situations where you do not want to use the default permission levels; for example, when a
default permission level includes all the permissions that your users need, except the one that they require
to do their job. In this scenario, you could add another permission to this permission level. On the other
hand, if a default permission level has a permission that you do not want to grant to your users, you could
remove that specific permission from the default permission level.
Best Practice: If you have several adjustments to make to a default permission level, it is
best practice to create a new custom permission level and add the required permissions to it.
Managing permission levels

You manage permission levels by accessing the Site Settings page. On the Site Settings page, under
Users and Permissions, open Site permissions. You then use the Permission Levels button on the
ribbon to open the Permission Levels page. From here, you can add a new permission level, delete a
permission level or modify an existing permission level.
Perform the following steps to add a new permission level:
1.
Click Add a Permission Level.
2.
Provide a name and description for the new permission level.
3.
Use the check boxes to select the individual permissions you want include in the new permission level.
4.
Click Create.
Perform the following steps to delete a permission level:

1.
Select the check box for an existing permission level.
2.
Click Delete Selected Permission Level.
3.
In the message dialog box, click OK.
Perform the following steps to modify an existing permission level:

1.
Click the name of the permission level.
2.
You can modify the name, description, and the individual permissions of a permission level.
3.
After you finish modifying it, click Submit.
Managing SharePoint Groups

SharePoint groups are used to make permission
administration simpler because they contain a set
of users that you can manage and assign
permissions together. One of the key decisions
you need to make about the security of your sites
and their contents in SharePoint 2013 is how to
group your users and which permission levels to
assign.
Default SharePoint groups

The default groups that are available to you in
SharePoint 2013 depend on the type of site you
create, which is based on the site template used to
create it.
For example, if you create a site using the Team Site or Blog template, the following four standard
SharePoint groups become available, which are common to nearly all of the site templates:
Owners
Members
Visitors
Viewers
However, if you create a site using the Enterprise Wiki or Business Intelligence (BI) site template, the
following groups become available along with the standard default groups:
Approvers
Designers
Hierarchy Managers
Restricted Readers
Translation Managers
Default SharePoint group permission levels

Each of the default SharePoint groups has a default permission level assigned to them:
Owners group. This group is assigned the Full Control permission level. Any user with Full Control
permission can create also custom SharePoint groups.
Members group. This group is assigned the Contribute permission level.
Visitors group. This group is assigned the Read permission level.
Viewers group. This group is assigned the View Only permission level.
Additional Reading: For information about permission levels, see Managing Permission
Levels earlier in this lesson.
How to manage SharePoint groups
8-7
You define SharePoint groups and their respective permission levels at the site collection level. Like other
permissions in SharePoint, they are inherited from the parent object by default.
Perform the following steps to create a new SharePoint group:

1.
On the site collection Home page, click the Settings icon, and then click Site settings.
2.
On the Site Settings page, under Users and Permissions, click People and groups.
3.
On the People and Groups page, in the left navigation, click Groups.
4.
Click New.
5.
On the Create Group page:

o
Specify a name and optional description for the new SharePoint group.
Specify the owner of this SharePoint group.
Specify who can view and edit the membership of this group.
Specify the settings you want for requests to join or leave the group.
Specify the permission level you want for this SharePoint group.
Create the group.
Perform the following steps to add users to a SharePoint group:
8-8
1.
2.
3.
On the People and Groups page, in the left navigation, click the name of the group you want to add
users to.
4.
On the People and Groups: GroupName page, click New.
5.
In the Add people to the GroupName group box, add names by typing the names or email
addresses of the users you want to add.
6.
Click Share to add users to the group.
Perform the following steps to grant permissions to a SharePoint group:

1.
2.
On the Site Settings page, under Users and Permissions, click Site permissions.
3.
Select the check box of the group you want to grant permissions to.
4.
In the Modify section of the ribbon, click Edit User Permissions.
5.
On the Permissions: Edit Permissions page, select the check boxes for the permissions you want this
group to have.
6.
Click OK.
Changing site group associations

In some circumstances, you may want to change the group that is specifically associated with an
individual site; by default, this is usually the Members group. This group will be the default group that
new users get added to for the site.
How to change the default group for a site

Perform the following steps to change the default group for a site using Central Administration:
1.
On the site collection Home page, click the Settings icon and then click Site settings.
2.
3.
On the People and Groups page, in the left navigation, click the name of the group you want to
change the default group for.
4.
Click Settings, and then click Make Default Group.
5.
Verify you want to make this group the default group for the site.
Note: You can also programmatically change the associated group for a site in Windows
PowerShell, by using the Get-SPWeb and Set-SPWeb cmdlets with the
AssociatedOwnerGroup, AssociatedMemberGroup, and AssociatedVisitorGroup properties.
This is useful if you are scripting the creation and management of multiple sites.
Managing Web Application Policies

Because web applications contain multiple site
collections, managing the permissions for those
site collections can be challenging. This is
particularly true if you have access needs for some
users that are different to the needs of the
majority of users that your web application
permissions apply to.
Web application policies

Web application policies are the solution to this
challenge; you can use web application policies to
centrally manage the permissions that apply to all
site collections in your web application and to
specify policies that apply to only a subset of users with different permission requirements. You can
configure the following policy options from the Central Administration website:
8-9
User Policy. This setting enables you to configure a policy that defines broad permission policies for
users in the web application. You can add users to a permission policy, edit the policy settings, and
delete users from a permission policy.
Anonymous Policy. This setting enables you to configure a policy to enable or disable anonymous
access for a web application. When 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
required.
Permission Policy. This setting enables you to configure the existing permission policy levels that you
assign in the User Policy setting listed earlier and to create and define your own custom levels that
can also be applied in the User Policy setting. You create these new permission levels by using a
combination of List, Site, and Personal permissions. This policy setting also enables you to specify
two site collection-specific permission levels: Site Collection Administrator and Site Collection
Auditor.
Note: You should use web application policies judiciously, because users who are granted
permissions through a web application policy will have access to every site collection within the
web application. Furthermore, these permissions are not visible to site collection administrators,
which can make security auditing more challenging.
Managing user policies
8-10 Managing Users and Permissions
To manage a user policy, in Central Administration, in the Application Management section, click
Manage web applications. Then you can select the web application whose policy you want to manage,
and in the Policy group of the ribbon, click User Policy.
Perform the following steps to add users to a user policy:
1.
Click Add Users.
2.
Select the zone you want the user policy to apply to.
3.
Add the users that you want to add to the user policy.
4.
Select the permissions that you want the user policy to apply.
5.
Optionally, you can specify whether a user account should operate as the System account.
Perform the following steps to delete users from a user policy:

1.
Select the user or group you want to remove from the user policy.
2.
Click Delete Selected Users.
3.
Verify that you want to delete the selected user.
Perform the following steps to edit the permissions of selected users in a user policy:
1.
Select the user or group you want to edit the user policy permissions for.
2.
Click Edit Permissions of Selected Users.
3.
Modify the user policy permissions.
4.
Optionally, you can specify whether a user account should operate as the System account.
Managing anonymous policies

To manage an anonymous policy, in Central Administration, in the Application Management section,
click Manage web applications. Then you can select the web application whose policy you want to
manage, and in the Policy group of the ribbon, click Anonymous Policy.
Additional Reading: For information about managing anonymous access policies, see
Managing Anonymous Access later in this module.
Managing permission policies
To manage a permission policy, in Central Administration, in the Application Management section, click
Manage web applications. Then you can select the web application whose policy you want to manage,
and in the Policy group of the ribbon, click Permission Policy.
Perform the following steps to add a new permission policy level:
1.
Click Add Permission Policy Level.
2.
Provide a name and description for the new permission policy level.
3.
Grant site collection permissions if required.
4.
Select the individual permissions for this permission policy level.
5.
Save the policy.
Perform the following steps to delete a permission policy level:

1.
Select the permission policy level(s) you want to delete.
2.
Click Delete Selected Permission Policy Levels.
3.
Verify that you want to delete the selected permission policy level(s).

Scenario
server farm consists of three servers: a domain controller, a SQL Server 2012 server, and a SharePoint 2013
server. Your team has installed SQL Server 2012, and SharePoint Server 2013. You have been assigned to
set up users, groups, and permissions on the intranet until governance and training are in place; at which
point, permission management will be delegated to site collection administrators. Additionally, you must
configure SharePoint to support the business requirement that the internal security and compliance audit
team has the ability to access all information stored on the intranet.
Objectives
Create a web application policy.
Create and manage SharePoint groups.
Create custom SharePoint permission levels.
Virtual Machine: 20331B-NYC-DC-08, 20331B-NYC-SP-08
Password: Pa$$w0rd
Virtual Machine 20331B-NYC-DB-08
Password: Pa$$w0rd
Virtual Machine 20331B-NYC- DB-08
Password: Pa$$w0rd
Password: Pa$$w0rd
Password: Pa$$w0rd
Exercise 1: Creating a Web Application Policy

Scenario
In this exercise, you will create a new web application policy.
You will create new security groups in Active Directory, which will make it easy for domain administrators
to grant user permissions to access SharePoint sites without granting permissions in SharePoint. You will
create user policies to associate those user groups with existing and new web application policies.
Finally, you will use multiple virtual machines to connect to a SharePoint site as different users, and verify
that the permissions defined by your web application policies are working correctly.

1. Create Active Directory security groups
2. Create a web application permission policy
3. Create a web application user policy
4. Test the permission and user policies
Task 1: Create Active Directory security groups
Log on to the 20331B-NYC-DC-08 virtual machine as Contoso\administrator with the password

Pa$$w0rd.
Create a new group with the following details.

Group name
SharePoint Content Auditors
Group (SamAccountName) name
SharePoint Content Auditors
Type
Security
Scope
Global
Members
[email protected]

Group name
SharePoint Full Control
SharePoint Full Control
Type
Security
Scope
Global

Group name
SharePoint Deny Access
SharePoint Deny Access
Type
Security
Scope
Global

Group name
SharePoint Read Only
SharePoint Read Only
Type
Security
Scope
Global
Task 2: Create a web application permission policy
Log on to the 20331B-NYC-SP-08 virtual machine as Contoso\administrator with the password

Pa$$w0rd.
Browse to the Web Application Management page.
Create a new web application permissions policy for the SharePoint - sharepoint.contoso.com80
web application with the following properties.
Name
Content Auditors
Site Collection Auditor site collection permission
Granted
View items list permission
Granted
Open items list permission
Granted
View versions list permission
Granted
View pages site permission
Granted
Open site permission
Granted
All other permissions
Neither granted nor denied
Task 3: Create a web application user policy
Create a new User Policy for the SharePoint - sharepoint.contoso.com80 web application with the
Zones
Users
CONTOSO\SharePoint Content Auditors
Permissions
Content Auditors
Zones
All zones
Users
CONTOSO\SharePoint Full Control
Permissions
Full Control
Zones
All zones
All zones
Users
CONTOSO\SharePoint Deny Access
Permissions
Deny All
Zones
All zones
Users
CONTOSO\SharePoint Read Only
Permissions
Full Read
Task 4: Test the permission and user policies
In Internet Explorer, browse to http://sharepoint.contoso.com. Log on as Contoso\administrator

with the password Pa$$w0rd.
On the SharePoint site, browse to the Documents document library.
Upload the SampleDocument.docx Word document from the E:\Mod08 folder to the SharePoint
Documents document library.
Verify that you can edit properties of the Sample Document document.
Log on to the 20331B-NYC-DB-08 virtual machine as Contoso\jim with the password Pa$$w0rd.
Open Internet Explorer and navigate to http://sharepoint.contoso.com. Log on as Contoso\jim

Verify that you cannot add a new document.
Verify that you can view the SampleDocument, but that you cannot edit any properties.
Results: After completing this exercise, you should have created a new web application policy, and
associated Active Directory security groups with web application policies.
Exercise 2: Creating and Managing SharePoint Groups

Scenario
In this exercise, you will add users to existing SharePoint groups. You will test the permissions granted to
those users, and then you will create a new SharePoint group and test that user group.
1. Add a user to a site's Members SharePoint group
2. Verify that the member has the permissions required to edit content
3. Add a user to a site's Visitors SharePoint group
4. Verify that the visitor has permissions to view the site but not create or edit content
5. Create a new SharePoint group and assign the group the Design permission level
6. Add a user to the new Designers SharePoint group
7. Verify that the designer can customize the appearance of the site
Task 1: Add a user to a site's Members SharePoint group
Add [email protected] to the Contoso Intranet Portal Members SharePoint security group.
Task 2: Verify that the member has the permissions required to edit content
Switch to the 20331B-NYC-DB-08 virtual machine.
Refresh the SharePoint site.
Verify that you can now add a new document.
Verify that you can both view and edit the SampleDocument properties.
Task 3: Add a user to a site's Visitors SharePoint group
Add [email protected] to the Contoso Intranet Portal Visitors SharePoint security group.
Task 4: Verify that the visitor has permissions to view the site but not create or edit
content
Switch to the 20331B-NYC-DB-08 virtual machine. If you are not already logged off, log off.
Log on as Contoso\ray with the password Pa$$w0rd.
Open Internet Explorer and navigate to the http://sharepoint.contoso.com site. Log on as

Contoso\ray with the password Pa$$w0rd.
Verify that you cannot add a new document.
Verify that you can view the SampleDocument, but that you cannot edit any properties.
Task 5: Create a new SharePoint group and assign the group the Design permission
level
Create a new group named Designers, and grant it the Design permission level.
Task 6: Add a user to the new Designers SharePoint group
Add [email protected] to the Designers SharePoint security group.
Task 7: Verify that the designer can customize the appearance of the site
Log on as Contoso\toni with the password Pa$$w0rd.
Open Internet Explorer and navigate to http://sharepoint.contoso.com. Log on as Contoso\toni

Edit the SharePoint site Home page by removing the Get started with your site Web Part from the
page.
View the Home page for the SharePoint site to verify that the change made by Toni affects all users.
Results: In this exercise, you should have created a new SharePoint group, and added users to both the
default and custom SharePoint groups.
Exercise 3: Creating Custom Permission Levels

Scenario
In this exercise, you will create a custom permission level. You will then create a new SharePoint group
and assign the group your new permission level. You will test the permission level by adding a user to the
group and using that account to verify that the user has the correct access level.
1. Create a custom permission level that enables users to view usage data
2. Create a new SharePoint group and assign the group the View Usage Data permission
3. Add a user to the new Usage Monitors SharePoint group
4. Verify that the usage monitor cannot view usage reports
5. Add additional permissions to the View Usage Data permission level
6. Verify that the usage monitor can view usage reports
Task 1: Create a custom permission level that enables users to view usage data
View the existing permissions levels for the sharepoint.contoso.com site collection.
Create a new permission level named View Usage Data, which grants the View Web Analytics Data
site permission.
Task 2: Create a new SharePoint group and assign the group the View Usage Data
permission
Create a new group named Usage Monitors, and grant it the View Usage Data permission level.
Task 3: Add a user to the new Usage Monitors SharePoint group
Add [email protected] to the Usage Monitors SharePoint security group.
Task 4: Verify that the usage monitor cannot view usage reports
Log on as Contoso\will with the password Pa$$w0rd.
Open Internet Explorer and navigate to http://sharepoint.contoso.com. Log on as Contoso\will

with the password Pa$$w0rd. Verify that you are denied access to the site.
In Internet Explorer, navigate to the http://sharepoint.contoso.com/_layouts/usage.aspx page.

Again verify that you are denied access.
Note: Although you have granted the CONTOSO\Will account access to the analytics data,
you have not granted permissions to view the default application pages that present the data. In
the next task, you will add additional permissions to resolve this problem.
Task 5: Add additional permissions to the View Usage Data permission level
Edit the View Usage data permission level by additionally granting the View Application Pages list
permission.
Task 6: Verify that the usage monitor can view usage reports
In Internet Explorer, navigate to the http://sharepoint.contoso.com site. Verify that you are still
denied access to the site.
In Internet Explorer, navigate to the http://sharepoint.contoso.com/_layouts/usage.aspx page.

Verify that you can now access the analytics reports.
Results: In this exercise, you should have created a custom permission level, assigned that permission to a
user group, and then tested the user group by using a non-administrative user account.
Lesson 2
Managing Access to Content
8-19
In this lesson, you will learn about the concept of permission inheritance in SharePoint 2013, and how to
manage key access management elements, such as anonymous access, site access requests, App
permissions, and HTML field security.
Lesson Objectives
Understand permission inheritance in SharePoint 2013.
Manage anonymous access in SharePoint 2013.
Manage site access requests in SharePoint 2013.
Manage App permissions in SharePoint 2013.
Configure HTML Field Security in SharePoint 2013.
Understanding Permission Inheritance

In SharePoint 2013, when you set permissions on
the root site in a site collection, securable
objectssuch as sites, lists, folders, and
documentsinherit their permissions from parent
objects above them in the site hierarchy by
default.
Permission inheritance
Using this default behavior of permission
inheritance provides an easy way for you to
administer and secure objects in a site collection.
However, there may be situations where you want
to use a more granular approach to assigning
permissions.
Stopping permission inheritance
To be able to use more fine-grained permissions on child objects in the site hierarchy, you need to stop
the permission inheritance filtering down from parent objects above them. After you do this, you can then
assign unique permissions directly on those child objects in order to achieve more control over the actions
your users can perform on site collection objects.
When you stop inheriting permissions from a parent object, the users, groups, and permission levels are
copied down from the parent object to the child object, and then inheritance is broken. When this occurs,
all the permissions become explicit, and any future permission changes made to the parent object no
longer affect the child object.
If you decide to start inheriting again, the permissions are copied back down from the parent, and all
explicit permissions are removed from the child object.
Best Practice: To reduce your administration overhead in SharePoint 2013, it is a best
practice to use permission inheritance wherever possible.
How to stop permission inheritance

The basic steps to stop permission inheritance include:
Open the Settings page for the content object you want to stop inheritance on.
Open the Permission Settings page.
Stop the content object from inheriting permissions from its parent object.
Remove any users or groups that you no longer want to have access to the object.
Grant explicit permissions to new users or groups that you do want to have access to the object.
Perform the following steps to stop permission inheritance on a library object:

1.
Navigate to the site Library page, and then click the LIBRARY tab.
2.
On this tab, click Library Settings.
3.
Under Permissions and Management, click Permissions for this document library.
4.
Note the message at the top: This library inherits permissions from its parent.
5.
Click Stop Inheriting Permissions.
6.
In the Message from webpage dialog box, click OK.
7.
Note the new message at the top: This library has unique permissions.
How to re-establish permission inheritance

The basic steps to re-establish permission inheritance include:
Open the Settings page for the content object you want to re-establish permission inheritance for.
Open the Permission Settings page.
Delete the unique permissions. Deleting the unique permissions also re-establishes permission
inheritance and copies back the inherited permissions.
Perform the following steps to reestablish permission inheritance on a library object:

1.
Navigate to the site Library page, and then click the LIBRARY tab.
2.
On this tab, click Library Settings.
3.
Under Permissions and Management, click Permissions for this document library.
4.
Note the message at the top: This library has unique permissions.
5.
Click Delete unique permissions.
6.
7.
Note the new message at the top: This library inherits permissions from its parent.
Permission inheritance planning
If you have an organized hierarchy of permissions and inheritance, it becomes much easier to control and
manage your site permissions. However, if you have a mixture of inherited and explicit fine-grained
permissions spread over different levels in your site hierarchy, it becomes much harder to manage, and
therefore, keep secure. It is much better to arrange your site structure to allow them to share permissions
wherever possible. For example, you could segregate your site content by security level, so that you have
a specific site, folder, or library with explicit permissions for more sensitive data. However, bear in mind
that the new Share menu item can make it more challenging to plan and manage permission structures.
Managing Anonymous Access

Anonymous access, as the name suggests, allows
anonymous users to view pages. Most publicfacing Internet websites use this type of access.
Some websites may also require you to provide
logon credentials to allow access to other, more
restricted areas of the website; for example, on a
corporate website that has some internal access
areas, or when purchasing goods on a website.
Anonymous access
8-21
Anonymous access uses the IUSR anonymous user

account that is maintained in Internet Information
Services (IIS). Therefore, when you enable
anonymous access for a SharePoint 2013 site, you are actually granting the IUSR account the View Items
permission on objects in the site.
In SharePoint 2013, anonymous access is disabled by default, but it can be enabled either at the time of
creating the web application or later if needed. If enabled, other site administrators can then grant
anonymous access to sites or site content as requirements dictate.
Best Practice: To maintain web application and site security, it is a best practice to not
enable anonymous access unless it is absolutely vital to do so.
Enabling anonymous access for a web application
Perform the following steps to enable anonymous access if you did not choose to do so when you created
the web application:
1.
2.
Select the web application you want to enable anonymous access for.
3.
In the Security group on the ribbon, click Authentication Providers.
4.
In the Authentication Providers dialog box, under Zone, click Default.
5.
On the Edit Authentication page, select the Enable anonymous access check box.
6.
Click Save.
7.
Close the Authentication Providers dialog box.
Enabling anonymous access for a site collection
Perform the following steps to enable anonymous access for a specific site collection and not the entire
web application:
1.
On the Home page of your site collection, click the Settings icon, and then click Site settings.
2.
Under Users and Permissions, click Site permissions.
3.
On the ribbon, in the Manage group, click Anonymous Access.
4.
In the Anonymous Access dialog box, click one of the following:

o
Entire web site. This allows anonymous users to browse the entire site, and view all lists, libraries,
and items that inherit permissions from the site.
Lists and libraries. This allows anonymous users to view the lists and libraries on which the View
Items permission has been granted to anonymous users.
Nothing. This blocks anonymous users from accessing any part of the site or its contents.
Configure anonymous access permissions for lists and libraries

If you select either the Entire web site or Lists and libraries options described earlier, you can then
configure anonymous access permissions on lists and libraries in the site.
Perform the following steps to configure anonymous access permissions for a list:
1.
Open the list on which you want to configure anonymous access permissions.
2.
On the LIST tab, in the Settings group, click List Settings.
3.
In the Permissions and Management column, click Permissions for this list.
4.
On the PERMISSIONS tab, in the Manage group, click Anonymous Access.
Note: The Manage group and Anonymous Access option are not available on the
PERMISSIONS tab if your list or library is inheriting permissions from its parent site. To configure
anonymous access permissions on a list or library that is inheriting permissions from the site, you
must first stop the inheritance setting.
5.
In the Anonymous Access dialog box, select one or more of the following permissions to grant to
your anonymous users for this list:
o
Add Items
Edit Items
Delete Items
View Items (On by default)
Managing anonymous policies
Web application permission policies provide a method for you to centrally control and manage
permissions for users and groups in a web application. You manage permission policies for anonymous
users by defining an anonymous policy for your web application.
Perform the following steps to manage an anonymous policy:
1.
In Central Administration, in the Application Management section, click Manage web applications.
2.
Select the web application whose policy you want to manage.
3.
In the Policy group on the ribbon, click Anonymous Policy.
Note: If all the options are unavailable in the Anonymous Access Restrictions dialog box,
perform the steps outlined earlier in How to Enable Anonymous Access to enable anonymous
access for your web application first.
4.
Select the zone you want the anonymous policy to apply to.
5.
Select the permissions for the anonymous policy:

o
None. This default setting means that no policy is specified; anonymous users will be given the
same default permissions available to NT AUTHORITY\Authenticated Users and All Authenticated
Users.
Note: If anonymous access is allowed for the web application, site administrators need to
decide whether to grant anonymous access to a site or any of its content.
6.
8-23
Deny Write. This setting enables anonymous users to read all site collection content within a web
application, but they cannot write content to those site collections, even if a site administrator
grants the anonymous account that specific permission.
Deny All. This setting means anonymous users will have not have any access to the web
application, even if a site administrator grants specific access permissions to the anonymous
account on a site collection.
Save the anonymous policy.
Managing Site Access Requests

When a user attempts to access a site resource in
SharePoint 2013 but fails to get access, you can
use the improved Access Request and Invitations
feature to control whether the user should be
granted access.
Access requests have been in the product since
SharePoint 2007, but the process has been
improved and streamlined in SharePoint 2013.
Access request improvements in

SharePoint 2013
Previously, when a user received the message that

access was denied, the user could click a link to request access and supply some text about the request,
which would send an email message to the site administrator. The site administrator had to regularly
check email to see whether any new access requests had arrived, and then respond to any access requests
that had arrived.
In SharePoint 2013, this system has been overhauled to allow the user to view status updates on any
access requests and also to engage in a two-way text conversation with the site administrator about the
requests. On the administration side of things, site administrators now have a centralized location to view
and manage access requests.
Enabling access requests and invitations
The first thing you need to do to enable access requests in SharePoint 2013 is configure your outgoing
email settings. This is configured at the farm level in Central Administration, under System Settings, in
the E-Mail and Text Messages (SMS) section.
You also need to enable access requests on the site. This setting is disabled by default.
Perform the following steps to enable access requests on a site:
1.
Log on as the site administrator, click the Settings icon, and then click Site Settings.
2.
Under Users and Permissions, open Site permissions.
3.
On the ribbon, on the PERMISSION tab, in the Manage group, click Access Request Settings.
4.
Allow access requests for the site, and provide an email address to send access requests to.
After you configure these settings, when a user tries to access a page to which they have no access, they
will receive an access denied error and a message will appear on the page saying Let us know why you
need access to this site.
The access request and invitations process

The basic process for approving access requests is as follows:
The user receives an access denied message.
The user types some information about the access request in the text box and then clicks Send
request.
The user receives a new message saying Awaiting approval. Well let you know about any updates.
The site administrator receives an email message regarding the access request.
The site administrator opens Site Settings, and under Users and Permissions, clicks Access requests
and invitations.
The site administrator clicks the ellipsis () to open the access request menu and approve the request
and grant an access permission level to the user.
The user can now access the site content.
Administering access requests
The site administrator can use either the Access requests and invitations page as described earlier, or
the site administrator can click the Settings icon on a site, click Shared with, and then click View
requests to see any pending access requests.
From here, the site administrator can decline or approve requests, and specify a permission to grant the
requesting user. Site administrators can also initiate a text conversation with the requesting user that will
appear on the access denied page. For example, if the site administrator decides to decline the request, a
message will appear on the access denied page saying Sorry, your request has been declined.
Viewing access request history
After requests are approved or declined, you can view the history of those requests by clicking the Show
History link on the Access Requests page.
Managing App Permissions

Apps in SharePoint 2013 offer various tools and
advanced functions to improve the effectiveness
of your SharePoint 2013 farm. Apps are small, selfcontained applications that provide solutions to
meet end-user or organizational needs. Site
owners and administrators can download
SharePoint apps either from an internal corporate
App Catalog, or from an online public app store.
There are several things to consider if you plan to
use SharePoint apps in your farm, including:
Who can install apps?
Who can use apps?
What is the scope of the apps?
What permission levels do the apps require?
How will apps be authorized?
Additional Reading: For more information about apps, see Overview of apps for
App permissions management in SharePoint 2013
App permissions management helps you to control the ability of apps to access and utilize your site
resources and to carry out actions on behalf of your users. App authentication uses a trusted token service
to issue access tokens to apps; these tokens are limited by time and scope. App authentication verifies the
authentication claims of an app and its ability to act on behalf of an authenticated user in SharePoint
2013.
App authorization verifies that an app that has already been authenticated has the required permissions
to access site resources and perform specific tasks.
You use app permissions to control who can purchase and install apps and who can then use those
installed apps. When planning your app permissions, you need to define which resources in SharePoint
2013 the apps will require access to, and what level of permission they require to perform their intended
function successfully.
You will also need to decide on an appropriate authorization policy for your apps.
Additional Reading: For more information about app permissions, see Plan app
permissions management in SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299626
App permission request scopes
Apps in SharePoint 2013 use app permission request scopes and permission requests to specify the level
at which the app is supposed to run, and the permission level that is assigned to the app. App permission
request scopes indicate where in the SharePoint 2013 hierarchy a permission request will be applied.
SharePoint 2013 supports the following request scopes for app permissions:
SPSite. Defines the app permission request scope as a SharePoint 2013 site collection.
SPWeb. Defines the app permission request scope as a SharePoint 2013 website.
SPList. Defines the app permission request scope as a SharePoint 2013 list.
Tenancy. Defines the app permission request scope as a SharePoint 2013 tenancy.
App permission requests
App permission requests are combinations of permissions that define what activities an app is allowed to
perform within the app permission request scope. SharePoint 2013 supports four app permission request
levels:
Read-Only. Enables apps to view pages, list items, and download documents.
Write. Enables apps to view, add, update, and delete items in existing lists and document libraries.
Manage. Enables to view, add, update, delete, approve, and customize items or pages within a
website.
Full Control. Enables apps to have full control within the specified scope.
App authorization policies
In addition to needing to define app permission request scopes and app permission request scope levels,
you also need to define app authorization policies.
There are four app authorization policies available in SharePoint 2103, including:
User and app policies. Authorization will only succeed if both the current user and the app have the
appropriate permissions to perform the tasks that the app is intended to perform.
App-only policies. Authorization will succeed if the app has appropriate permissions to perform the
tasks that the app is intended to perform. This policy is required when the app is not acting on behalf
of an authenticated user.
User-only policies. Authorization will succeed if the user has appropriate permissions to perform the
tasks that the app is intended to perform. This policy is required when a user accesses their own
resources.
Additional Reading: For more information about configuring app authentication and
permissions, see Configure app authentication in SharePoint Server 2013 at
Additional Reading: For more information about Windows PowerShell cmdlets for
managing apps in SharePoint 2013, see App Management Service cmdlets in SharePoint 2013 at
Configuring HTML Field Security

The HTML Field Security setting is a new feature in
SharePoint 2013 that enables you to specify
whether contributors to the site are allowed to
insert iframe elements from external domains into
HTML fields on your sites pages. Typically, these
iframe elements are used to embed dynamic
content, such as map directions and video content
into site pages.
There are some well-known external domains that
have already been granted this capability. You will
see the names of these domains when you
configure the security settings for your sites HTML
fields.
Defining HTML field security settings

You define HTML field security settings at the site collection level.
Perform the following steps to define HTML field security settings:
1.
2.
Under Site Collection Administration, click HTML Field Security.
3.
On the Site Settings: HTML Field Security page, you can choose one of the following options:
o
Do not permit contributors to insert iframes from external domains into pages on this site.
Contributors will receive an error message.
Permit contributors to insert iframes from any external domain into pages on this site. Contributors
will be able to insert iframe content from any domain.
Permit contributors to insert iframes from the following list of external domains into pages on this
site. Contributors will be able to insert iframe content from trusted domains only.
This is the default setting and it allows you to manually add trusted domains to a list that you will allow
iframes from. This list already contains some common domains that supply embedded dynamic content,
such as YouTube.com and Bing.com.
Note: Any subdomains of domains listed in this box are also automatically trusted.
Note: Important:: These settings do not apply to any content placed in scriptable Web
Parts. Users who have the right to add scriptable Web Parts to your site will be able to add
iframes from any domain, irrespective of these settings.

Scenario
server. Your team has installed SQL Server 2012, and SharePoint Server 2013. You have been assigned to
help set up users, groups, and permissions on the intranet until governance and training are in place; at
which point, permission management will be delegated to site collection administrators. To simplify the
process, you want to enable users to request access to sites. To help ensure that a user granted access to a
site does not gain access to content that should be restricted, you will configure bespoke permissions on
items in a site. In addition, Contoso wants to launch a website, but it does not want to require user names
and passwords to access that site, so you must configure a site collection for anonymous access.
Objectives
Manage permissions and inheritance within a SharePoint site collection.
Configure general security settings within a SharePoint site collection.
Enable anonymous access to a SharePoint site collection.
Virtual Machine: 20331B-NYC-DC-08, 20331B-NYC-SP-08
Password: Pa$$w0rd
Password: Pa$$w0rd
Password: Pa$$w0rd
Password: Pa$$w0rd
Exercise 1: Managing Permissions and Inheritance

Scenario
In this exercise, you will stop permissions inheritance, and define custom permissions for a folder. You will
then test the new permissions by attempting to view the folder by using non-administrative user
accounts.
1. Create a new folder in the Documents library, and verify that site members and visitors can view the
folder
2. Disable permission inheritance and define custom permissions for a folder
3. Verify that site members cannot see the folder with custom permissions
Task 1: Create a new folder in the Documents library, and verify that site members
and visitors can view the folder
Create a new folder in the Documents library named Reports.
Open Internet Explorer and navigate to the http://sharepoint.contoso.com site. Log on as

Contoso\toni with the password Pa$$w0rd.
On the SharePoint site, browse to the Documents document library. Verify that you can see the
Reports folder.
Log off.
Log on as Contoso\ray with the password Pa$$w0rd (Ray is a member of the Visitors group).
Open Internet Explorer and navigate to http://sharepoint.contoso.com. Log on as Contoso\ray

On the SharePoint site, browse to the Documents document library. Verify that you can see the
Reports folder.
Task 2: Disable permission inheritance and define custom permissions for a folder
Disable permission inheritance for the Reports folder in the Documents document library.
Remove all existing permissions on the Reports folder.
Grant [email protected] edit permissions on the Reports folder. Do not send an email invitation.
Task 3: Verify that site members cannot see the folder with custom permissions
Open Internet Explorer and navigate to http://sharepoint.contoso.com. Log on as Contoso\toni

On the SharePoint site, browse to the Documents document library. Verify that you cannot see the
Reports folder.
Log off.
Open Internet Explorer and navigate to http://sharepoint.contoso.com. Log on as Contoso\ray

On the SharePoint site, browse to the Documents document library. Verify that you can still see the
Reports folder (Ray was explicitly granted permission to access this folder).
Results: After completing this exercise, you should have defined custom permissions for a folder in a
document library, and tested those permissions by using non-administrative user accounts.
Exercise 2: Managing Site Collection Security

Scenario
In this exercise, you will control access to a site collection, and enable users to request access to a site
collection. You will approve an access request to access the site and verify that the non-administrative
user has access after approval.
Finally, you will review HTML field security settings. You will configure HTML field security settings to
prevent users from adding iframes, which load external domains to pages within the site collection.
1. Attempt to access a site with a non-authorized account
2. Enable access requests for the sharepoint.contoso.com site
3. Request access to a site
4. Approve an access request for a site
5. Attempt to access a site with the approved account
6. Configure HTML field security
Task 1: Attempt to access a site with a non-authorized account
On the 20331B-NYC-DB-08 virtual machine, if you are not already logged off, log off.
Log on as Contoso\neil with the password Pa$$w0rd.
Open Internet Explorer and navigate to http://sharepoint.contoso.com. Log on as Contoso\neil

with the password Pa$$w0rd. Verify that you are denied access to the site and cannot request access
to the site.
Task 2: Enable access requests for the sharepoint.contoso.com site
Open Internet Explorer and navigate to http://sharepoint.contoso.com. Log on as

Contoso\administrator with the password Pa$$w0rd.
View the site permissions for the sharepoint.contoso.com site.
Enable access requests for the site. Access requests should be sent to
[email protected].
Task 3: Request access to a site
In Internet Explorer, navigate to http://sharepoint.contoso.com. Verify that you are still denied
access but that you can now request access to the site.
Request access to the site with the message I need access to this site.
Task 4: Approve an access request for a site
Browse to the Site Settings page for the SharePoint site.
View the access requests for the SharePoint site.
Approve the pending request from Neil.
Task 5: Attempt to access a site with the approved account
In Internet Explorer, navigate to http://sharepoint.contoso.com. Verify that you now have access to
the site.
Task 6: Configure HTML field security
View the current HTML field security settings.
Change the HTML field security setting to prevent contributors from inserting any iframes from
external domains into pages on the site.
Browse to the home page for the sharepoint.contoso.com site.
Edit the page source by adding the following code, which adds an iframe with an external domain to
the start of the page.
<iframe src="http://www.blocked.contoso.com"></iframe>
After adding the code to the page source, close the page source, and verify that SharePoint warns
you that some code has been removed.
View the page source again and verify that the code you added has been removed.
Results: After completing this exercise, you should have enabled access requests and configured HTML
field security for a SharePoint site.
Exercise 3: Enable anonymous access to a site

Scenario
In this exercise, you will configure anonymous access to a site. You will create a new web application,
including configuring the necessary Domain Name System (DNS) and service account. You will then create
a site collection in the new web application and enable anonymous access to the site collection at the web
application and site collection levels. Finally, you will test that you can access the site without providing
credentials.
1. Configure a DNS record for the www.contoso.com web application
2. Create a service account for the www.contoso.com web application application pool
4. Create and configure a new web application
5. Create a root site collection
6. Enable anonymous access for the www.contoso.com web application
7. Enable anonymous access for the www.contoso.com site collection.
8. Test the www.contoso.com web application to ensure you can access it without providing credentials
Task 1: Configure a DNS record for the www.contoso.com web application
Open DNS Manager.
Name
IP address
www
172.16.1.21
Task 2: Create a service account for the www.contoso.com web application

application pool

Full name
WWW Application Pool
UPN logon
[email protected]
contoso\WWWAppPool
Password
Pa$$w0rd
Selected
Selected
Register the CONTOSO\WWWAppPool account you created in the previous task as a managed
account.
Task 4: Create and configure a new web application

IIS web site name
WWW - 80
Port
80
Host header
www.contoso.com
WWW - 80
CONTOSO\WWWAppPool
All other settings
Accept default setting
Task 5: Create a root site collection
www.contoso.com web application with the following properties.
Title
Internet Site
URL
http://www.contoso.com
Template
Publishing portal
Task 6: Enable anonymous access for the www.contoso.com web application
View the authentication settings for the Default zone of the www.contoso.com web application.
Enable anonymous access in the Default zone of the www.contoso.com web application.
Edit the anonymous user policy to help ensure anonymous users can access the site, but that they do
not have write access to the site.
Task 7: Enable anonymous access for the www.contoso.com site collection.
In Internet Explorer, navigate to the http://www.contoso.com site. Log on as

Browse to the Permissions page.
Enable anonymous access to the entire site.
Task 8: Test the www.contoso.com web application to ensure you can access it
without providing credentials
In Internet Explorer, navigate to http://www.contoso.com. Verify that you can access the site
without providing credentials.
Results: After completing this exercise, you should have configured a site for anonymous access.
In this module, you have learned about the key management concepts for SharePoint 2013, authorization
and permissions. You have also learned how to manage access to content in SharePoint 2013.
Review Question(s)
Test Your Knowledge
Question
Which of the following SharePoint groups is assigned the Contribute permission level
by default?
Viewers
Visitors
Owners
Members
Designers
Test Your Knowledge
Question
Which type of app authorization policy is needed when the app is not acting on behalf
of an authenticated user?
User and app policy
App-only policy
User-only policy
Any of the policies

9-1
Module 9
Configuring Authentication for SharePoint 2013
Contents:
Module Overview
9-1
Lesson 1: Overview of Authentication
9-2
Lesson 2: Configuring Federated Authentication
9-16
Lesson 3: Configuring Server-to-Server Authentication
9-27
Lab: Configuring SharePoint 2013 to Use Federated Identities
9-35
9-39
Module Overview
Authentication is the process by which you establish the identity of users and computers. Authorization
controls access to resources by assigning permissions to users and computers. To provide authorization to
consumers of Microsoft SharePoint content and services, whether they are end users, server platforms, or
SharePoint apps, you first need to verify that they are who they claim to be. Together, authentication and
authorization play a central role in the security of a SharePoint 2013 deployment by ensuring that
consumers can only access resources to which you have explicitly granted them access.
In this module, you will learn about the authentication infrastructure in SharePoint 2013. You will learn
how to configure SharePoint to work with a variety of authentication providers, and you will learn how to
configure authenticated connections between SharePoint and other server platforms.
Note: Authorization in SharePoint 2013 was covered in Module 8, Managing Users and
Permissions.
Objectives
Explain the authentication infrastructure of SharePoint 2013.
Configure claims providers and identity federation for SharePoint 2013.
Configure server-to-server authentication for SharePoint 2013.
Lesson 1
Overview of Authentication
9-2
Like most applications, SharePoint 2013 relies on external identity management systems to authenticate
users. By default, SharePoint 2013 uses claims-based authentication. You can configure SharePoint to
work with a wide range of claims providers across three broad areas: Windows authentication, formsbased authentication, and Security Assertion Markup Language (SAML) token-based authentication.
In this lesson, you will learn how SharePoint works with authentication providers to manage user
identities.
Lesson Objectives
Describe the authentication infrastructure in SharePoint 2013.
Explain the terminology used to describe claims-based authentication.
Describe the capabilities of Windows claims-mode authentication in SharePoint 2013.
Plan for Integrated Windows authentication using NT LAN Manager (NTLM) or Kerberos in a claims
authenticationbased SharePoint web application.
Configure a claims authenticationbased SharePoint web application to use Kerberos authentication.
Describe when and how to extend a SharePoint web application to additional zones.
Authentication Infrastructure in SharePoint 2013

Authentication is the process by which you
establish and verify the identity of users, service
accounts, or computers. SharePoint 2013 relies on
authentication in three areas:
User authentication. When a user attempts

to access a SharePoint resource, the
authentication provider must establish the
identity of the user. The SharePoint server can
then determine whether the user has
sufficient permissions to access the requested
resource.
App authentication. When a SharePoint app

that runs remotely attempts to access a SharePoint resource, the authentication provider must
establish the identity of both the app and the associated user before the SharePoint server can
authorize the request.
Server-to-server authentication. When a server requests access to a SharePoint resource on behalf

of a userfor example, an Exchange Server 2013 server retrieving information for a specific user
accountthe SharePoint server must verify the identity of the calling server. This authentication
process is based on a preconfigured trust relationship between the Security Token Service (STS) on
the SharePoint server farm and the STS on the calling server farm.
Note: SharePoint apps are a new concept in SharePoint 2013. Essentially, an app is a
custom SharePoint solution that contains no server-side code. Apps can run locally or remotely,
such as on the Windows Azure cloud platform. SharePoint app management is covered in course
20332, Advanced Solutions of Microsoft SharePoint Server 2013.
Claims-based authentication and Windows classic-mode authentication
In previous versions of SharePoint, when you created a new web application in Central Administration,
you were able to choose between claims-based authentication and Windows classic-mode authentication.
In SharePoint 2013, Windows classic-mode authentication is deprecated and is no longer available as an
option in Central Administration. You can still create a web application that uses classic-mode
authentication by using Windows PowerShell, but this is not recommended. Creating a web application
that uses Windows authentication in claims-mode requires no additional configuration compared to
creating a web application that uses Windows classic-mode authentication. The authentication experience
is the same in both cases for Windows credential users. In each case, users are authenticated in the same
way by Active Directory Domain Services (AD DS). In classic-mode, SharePoint uses the Windows identity
of the user directly. In claims-mode, SharePoint converts the Windows identity into a claims-based
identity token that it can pass to other services as appropriate.
Using claims-based authentication has several advantages over using Windows classic-mode
authentication:
App authentication and server-to-server authentication rely on claims-based authentication. If you

use Windows classic-mode authentication, you will be unable to use external SharePoint apps. You
will also be unable to use any services that rely on a trust relationship between SharePoint and other
server platforms, such as Office Web Apps Server 2013, Exchange Server 2013, and Lync Server 2013.
SharePoint can delegate claims identities to back-end services, regardless of the sign-in method. For
example, suppose your users are authenticated by NTLM authentication. NTLM suffers from a wellknown "double-hop" limitation, which means that a service such as SharePoint cannot impersonate
the user to access other resources on behalf of the user, such as SQL Server databases or web services.
By contrast, when you use claims-mode authentication, SharePoint can use the claims-based identity
token to access resources on behalf of the user.
When you create a web application in claims-based authentication mode, you can associate multiple
authentication providers with the web application. For example, you can support Windows-based
sign in and forms-based sign in without creating additional Microsoft Internet Information Services
(IIS) websites and extending your web application to additional zones.
Claims-based authentication is based on well-known open web standards and is supported by a

broad range of platforms and services.
Supported authentication types for claims-based authentication
When you create a SharePoint web application in claims-based authentication mode, you can use the
following authentication mechanisms:
Windows authentication. You can support Integrated Windows authentication (NTLM and
Kerberos), basic authentication, and digest authentication.
Forms-based authentication. You can support forms-based authentication by configuring an

ASP.NET membership provider, and optionally an ASP.NET role manager.
SAML tokenbased authentication. You can federate authentication to any platform or service that
issues Security Assertion Markup Language (SAML)based claims tokens, such as Active Directory
Federation Services (AD FS) or the Windows Live ID service.
Reference Links: For more information about the authentication infrastructure in

SharePoint 2013, see:
Authentication overview for SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299629
Authentication, authorization, and security in SharePoint 2013 at

Incoming claims: Signing into SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299631
Understanding Claims-Based Authentication

If you have not worked with claims-based
authentication before, you may be unfamiliar with
some of the terminology. This topic provides a
brief review of the key concepts and terms.
When you use claims-based authentication, your
applicationin this case, a SharePoint web
applicationrelies on an external identity
management system to authenticate users and
provide any required information about each user.
An application that relies on claims-based
authentication is said to be claims-aware. As a
claims-aware application, the SharePoint web
application relies on a trust relationship with the identity management system. This trust relationship is
essentially configured through the exchange of security certificates for public-key cryptography. When
the trusted identity management system sends an encrypted identity token to the SharePoint web
application, SharePoint knows that:
The identity management system has authenticated the user.
Any information about the user, such as his or her user name and role memberships, is valid.
When you work with claims-aware applications such as SharePoint, you are likely to encounter the
following terms:
9-4
Claim. A claim is an individual piece of information about a user, such as a name, an email address, or
a role membership. A claims-aware application will only believe a claim if it trusts the identity
management system that issued the claim.
Security token. A security token is a serialized set of claims that is digitally signed by the issuing
authority. Security tokens are presented to claims-aware applications alongside requests, and they
enable the application to authorize access to resources.
Issuing authority. The issuing authority is the external identity management system that issues
security tokens. Claims-aware applications trust the claims made in security tokens if they trust the
issuing authority. Issuing authorities are sometimes referred to as claims providers.
Security token service (STS). An STS is a web service that creates and issues digitally-signed security
tokens. In the case of an issuing authority, the STS is known as an Identity Provider STS (IP-STS). When
you federate identities between multiple systems to support single sign-on (SSO) scenarios, you also
rely on a Relying Party STS (RP-STS). An RP-STS receives identity tokens from a remote IP-STS,
validates the tokens based on the trust relationship between the STSs, and issues a new security token
to provide access to local claims-aware applications and services.
Relying party. A relying party is another term for a claims-aware application. The relying party is able
to extract and use claims from a security token. After configuring a trust relationship between a
claims-aware application and an issuing authority, you must typically register your application as a
relying party with the issuing authority in order to configure how claims are presented to your
application.
9-5
Security Assertion Markup Language (SAML). SAML is an open, XML-based standard that
represents claims in an interoperable format. Most STSs issue security tokens in SAML format. This
enables you to exchange and use security tokens across disparate platforms.
In ASP.NET applications such as SharePoint, the claims infrastructure is implemented by Windows Identity
Foundation (WIF) and the .NET Framework. WIF implements open web standards to ensure
interoperability with other platforms. For example, WIF-based STSs expose service endpoints that support
the WS-Trust specification, which describes how to request and receive security tokens.
Reference Links: For more information about claims-based authentication concepts, see
Claims-based identity and concepts in SharePoint 2013 at
http://go.microsoft.com/fwlink/?Linkid=299632 and A Guide to Claims-Based Identity and Access
Control, Second Edition at http://go.microsoft.com/fwlink/?Linkid=299633
The SharePoint Security Token Service Application

In claims-based authentication terms, an STS is a
web service that issues security tokens that
represent a verified user identity. These tokens
consist of one or more identity claims, such as the
user's account name, email address, or group
memberships. There are two key types of STS:
An Identity Provider STS (IP-STS) is used to

create and manage claims-based identities. An
IP-STS validates user credentials against an
identity store, such as AD DS, performs claims
aggregation, and issues a claims-based
security token.
A Relying Party STS (RP-STS) receives security tokens from an IP-STS, where a trust relationship has
been configured between the two STSs. The RP-STS validates that a received security token is trusted,
and then it issues a new security token to provide access to local resources.
In SharePoint 2013, as in SharePoint 2010, the Security Token Service application provides the core
functionality of an STS. The Security Token Service application performs the role of both an IP-STS and an
RP-STS, depending on the scenario. The functionality of the Security Token Service application underpins
many SharePoint 2013 features. For example:
When you sign in to a web application using Windows credentials, the Security Token Service
application converts your Windows identity into a claims identity. It augments the claims with
information from AD DS, where appropriate, and issues a claims-based security token.
When you configure a connection between your SharePoint server farm and another server platform,
such as Office Web Apps Server 2013 or Exchange Server 2013, you configure a trust relationship
between the SharePoint STS and the remote STS. The Security Token Service application provides IPSTS functionality if SharePoint is requesting information from another platform, or RP-STS
functionality if another platform is requesting information from SharePoint.
When you configure a SharePoint web application to allow SAML tokenbased authentication, the
token issuer is the IP-STS, and the Security Token Service application is the RP-STS.
9-6
The Security Token Service application is provisioned automatically when you create a SharePoint 2013
server farm. You cannot configure the service and you do not need to create service application
connections or proxies for the service.
Windows Claimsmode Authentication

Windows claimsmode authentication is the
default authentication type for new web
applications in SharePoint 2013. The process for
configuring Windows claimsmode authentication
in SharePoint 2013 is very similar to the process
for configuring classic Windows authentication in
previous versions of SharePoint. When a user
browses to a web application that uses Windows
claimsmode sign in, the authentication process
works as follows:
1.

authenticates the user (NTLM) or receives a
service ticket that confirms the user is authenticated (Kerberos).
2.
IIS passes a WindowsIdentity object, which represents an authenticated Windows user, to the
SharePoint server.
3.
SharePoint converts the WindowsIdentity object into a ClaimsIdentity object, which is a claimsbased representation of a user.
4.
The Security Token Service Application in SharePoint performs claims augmentation by querying
Active Directory Domain Services (AD DS) for additional user properties, such as security group
memberships.
5.
The Security Token Service Application issues a claims-based security token to represent the user for
authorization.
You can use a variety of authentication methods with Windows claimsmode sign in:
Integrated Windows authentication. Either NTLM or Negotiate (Kerberos or NTLM) authentication

methods can be used.
Basic authentication. In the same fashion as Windows authentication, basic authentication relies on
a set of credentials for the user in Active Directory. However, basic authentication enables a web
browser to submit credentials while making an HTTP request; therefore, the credentials are sent in
plain text, and unencrypted, to the server.
Digest authentication. Digest authentication provides the same functionality as basic authentication,
but with increased security. User credentials are encrypted instead of being sent over the network in
plain text.
Anonymous. Anonymous authentication enables users to connect to a web application without

providing credentials.
Integrated Windows authentication
If you choose to enable Integrated Windows authentication when you create a new web application, you
can select either NTLM or Negotiate (Kerberos). If you select Negotiate (Kerberos), IIS will send a
Negotiate security header when it responds to client requests. The Negotiate process will use Kerberos
authentication where possible, but it will fall back to NTLM if the server environment or the client does
not support Kerberos.
You can use NTLM authentication in a domain environment without performing any additional
configuration in SharePoint or IIS. Kerberos authentication does require additional infrastructure
configuration; in particular, you must configure service principal names (SPNs) for applications and
services in AD DS. The next topic, Planning for NTLM and Kerberos Authentication, provides more
information about this process, together with the advantages and disadvantages of each approach.
Basic and digest authentication
In the vast majority of cases, organizations that plan to use Windows claimsbased sign in with
SharePoint 2013 will use either NTLM authentication or Kerberos authentication. However, some
organizations still use web browsers or services that only support basic or digest authentication. In these
instances, SharePoint and IIS will need to be configured to permit these older approaches to
authentication.
When you create a new web application, you can opt to allow basic authentication in addition to, or
instead of, Integrated Windows authentication. If you decide to allow basic authentication in addition to
Integrated Windows authentication, the client will authenticate using Integrated Windows authentication
if the web browser supports it and will fall back to basic authentication if it does not. When you use basic
authentication, the user credentials are sent to the server as unencrypted plain text. For this reason, you
should not allow basic authentication unless you also plan to use Secure Sockets Layer (SSL) to encrypt
traffic between the client and the server.
When you use digest authentication, the user credentials are hashed using the MD5 algorithm and sent to
the server as a message digest. This is a more secure alternative to basic authentication in environments
that are unable to support Integrated Windows authentication. If you want to use digest authentication
with SharePoint 2013, you must enable the digest authentication protocol for the web application or web
application zone in IIS.
Reference Links: For more information about configuring basic and digest authentication
for SharePoint 2013, see:
Configure basic authentication for a claims-based web application in SharePoint 2013 at

Configure digest authentication for a claims-based web application in SharePoint 2013 at

Anonymous access
When you configure authentication settings for a web application, you can choose to allow anonymous
access in addition to your selected authentication types. After you enable anonymous access at the web
application level, site collection administrators can configure anonymous access at the site collection level
and grant permissions to anonymous users.
Planning for NTLM and Kerberos Authentication

In most SharePoint deployment scenarios that rely
on Windows authentication, you will use either
NTLM or Kerberos to authenticate your end users.
Generally, Kerberos is preferred because it is more
efficient and more secure. However, it requires
additional configuration and increases the
complexity of the deployment.
NTLM authentication
NTLM was introduced more than 15 years ago and
is the most established form of authentication in
Microsoft products.
9-8
When a user logs on to a computer, the user is prompted for a user name and password. The user name is
sent to the domain controller, but the password is never sent over the network. Instead, a hash of the
password is passed through a one-way hashing algorithm (the challenge) by both the client and the
domain controller through an encrypted challenge/response protocol. The client sends the result (the
response) to the domain controller. If the result matches what the domain controller obtained as a result,
the password entered by the user must have been correct, and the user is authenticated.
It gets more complicated when a user connects to a server, such as IIS on a SharePoint server. If the
SharePoint server is a member servernot a domain controllerit has no way of knowing the users
password. Therefore, when the user connects to the server, the server has to pass the authentication
request to a domain controller. If the domain controller responds to IIS that the user is valid, the
authentication succeeds.
Although NTLM is not the most efficient authentication method and is slightly less secure than Kerberos,
it is often chosen as the authentication method for SharePoint web applications because it is easy to set
up.
Kerberos authentication
Kerberos is the default authentication method for Windows clients and servers in an Active Directory
domain.
Kerberos uses a process that involves encrypted tickets to verify authenticity. When a user logs on and
authenticates with the domain, the domain controllers Key Distribution Center (KDC) issues the user a
Ticket Granting Ticket (TGT) that effectively represents that the user has been authenticated. For the
lifetime of the TGT10 hours by defaultthe user no longer needs to be authenticated.
When the user wants to connect to a service, such as a SharePoint web application that uses Kerberos
authentication, the client application returns to a domain controllers KDC, presents the TGT, which
confirms that the client has already been authenticated, and requests from a domain controller a service
ticket for the specific service to which the client will connect. The client then goes to the service and
presents the service ticket.
Because the entire process is encrypted with keys unique to each requestor (the client, the service, and the
domain), the service is able to examine the service ticket and determine that it is being presented by an
authenticated client. The service ticket contains the clients identity and roles; the session is established.
One of the benefits of Kerberos is that when the client connects to the service, the service does not have
to send back to the server and back to the client for the authentication to happen to a domain controller,
like it does in NTLM. Instead, the clients ticket for the service ensures the client has been authenticated.
This results in improved authentication performance for Kerberos compared with NTLM.
Another benefit is that Kerberos tickets can be delegatedforwarded or proxiedbetween tiers. For
example, a client connecting to a website provides a Kerberos ticket, and the website can pass the ticket
to a back-end data source that can authenticate the user for data access. The web tier does not need to
know the users password to achieve this double-hop authentication. The web tier also does not need
permissions to the back-end data source, because it is all done by using the authentication of the client.
Kerberos is considered by many organizations to be a preferable authentication mechanism because of
the following advantages:
More secure than NTLM. Kerberos protocols ensure mutual authentication, which prevents man in
the middle attacks, whereby a rogue service can pretend to be a domain controller and intercept
authentication requests from clients. Kerberos tickets also contain time stamps that reduce the
likelihood of replay attacks in which an authentication token can be intercepted and used later for
malicious purposes.
More scalable than NTLM. Kerberos supports authentication across trusted realms, and because it is
an industry standard, it is supported by platforms other than Windows.
Supports identity delegation. Delegation allows a service to impersonate a user without knowing the
users password. In addition, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2,
and Windows Server 2012 support constrained delegation, which adds an additional level of security
to the implementation of Kerberos in a Windows-based enterprise.
Reduced load on domain controllers. Kerberos requires fewer trips to a domain controller than NTLM
for authentication.
There are disadvantages to using Kerberos, including:
It requires additional steps to configure, whereas NTLM requires no additional configuration.
To use Kerberos authentication, clients must be able to connect to a KDC and an AD DS domain
controller. Generally, this is not an issue in intranet scenarios, but Internet-facing deployments are
rarely configured this way.
Basic and constrained Kerberos delegation

Identity delegation is one of the most important advantages of Kerberos authentication because it
enables SharePoint to connect to back-end services using the identity of the end user. The Kerberos
protocol supports two types of delegation: basic (or unconstrained) and constrained.
Basic delegation allows web applications to pass Kerberos tickets across domain boundaries within an
Active Directory forest, but not across forest boundaries. If your domain controllers run Windows Server
2012, constrained delegation allows web applications to pass Kerberos tickets across domain boundaries
but not across forest boundaries. If your domain controllers run earlier versions of Windows Server,
constrained delegation does not allow web applications to pass Kerberos tickets across domain or forest
boundaries.
Constrained delegation is not required for Kerberos to work with SharePoint 2013, but it is highly
recommended. The key advantage of constrained delegation is that it enables you to specify the backend services that an application pool identity is permitted to delegate user credentials. For example, you
may permit the application pool identity for a Business Data Connectivity service application to delegate
user credentials only to a specific SQL Server service. By contrast, unconstrained delegation enables the
application pool identity to delegate user credentials to any service. This effectively gives the application
pool identity access to any resources that the end user has access to, which is inherently less secure.
Best Practice: If you choose to configure constrained delegation, we recommend that you
test your Kerberos configuration with unconstrained delegation and resolve any issues you might
encounter prior to configuring constrained delegation.
9-10 Configuring Authentication for SharePoint 2013
Some SharePoint 2013 service applications can use Kerberos authentication to delegate identities using
either basic delegation or constrained delegation, whereas others require Kerberos to be configured for
constrained delegation. SharePoint 2013 can delegate identities using either basic or constrained
delegation for the following service applications and products:
Business Data Connectivity service application
Access Services
SQL Server Reporting Services
Project Server 2013
The following service applications require constrained delegation if you use Kerberos authentication:
Excel Services
PerformancePoint Services
InfoPath Forms Services
Visio Services
Constrained delegation is required by these service applications because they require the Claims to
Windows Token Service (C2WTS) to translate claims-based credentials into Windows credentials, and this
protocol transition is only supported by Kerberos constrained delegation.
Claims and Kerberos
The advent of claims-based authentication can obviate some of the reasons for using Kerberos instead of
NTLM. In particular, claims-based authentication enables SharePoint to pass claims tokens to back-end
services, regardless of the initial authentication method. However, SharePoint can do this only if you have
configured a trust relationship between the SharePoint server and the service, and if the service is claimsaware.
Discussion: Using Kerberos Authentication

The advent of claims-based authentication can
make the use of Kerberos less necessary in some
circumstances. Under what scenarios might you
still need to use Kerberos instead of NTLM
authentication?
Configuring Kerberos Authentication

Configuring Kerberos authentication requires that
you create service principal names (SPNs) for your
SharePoint services, web applications, and SQL
Server instances. When a client wants to connect
to a web application that uses Kerberos
authentication, the client requests a service ticket
from a domain controllers KDC. The request
indicates the service to which the client will
connect by specifying the services SPN.
The SPN is made up of the following three
components:
Service class for the request, which is always

HTTP (the HTTP service class includes both the HTTP and HTTPS protocols)
Host name
Port of the web application (if not port 80)
9-11
For example, a request to http://intranet.contoso.com on port 80 equates to an SPN of

HTTP/intranet.contoso.com. Note that the SPN syntax uses a single forward slash between the service
class and host name portions of the name. A request to http://SP2013-WEB1:9999 for Central
Administration equates to an SPN of HTTP/SP2013-WEB1:9999.
Note: A security principala user or computer account in Active Directorycan have more
than one associated SPN.
Kerberos authentication involves the following steps:
1.
When a domain controllers KDC receives the service ticket request from a client, it looks up the
requested SPN.
2.
The KDC then creates a session key for the service and encrypts the session key with the password of
the account to which the SPN is associated.
3.
The KDC issues a service ticket containing the session key to the client.
4.
The client presents the service ticket to the service.
5.
The service, which knows its own password, decrypts the session key, and then authentication is
complete.
If a client submits a service ticket request for an SPN that does not exist in the identity store, no service
ticket can be established, and the client will cause an access denied error to occur. For this reason, each
component of a SharePoint infrastructure that uses Kerberos authentication requires at least one SPN.
Note that it is the IIS application pool, not the server, that is associated with the SPN because the
application pool is the security context within which the servicethe web application in this caseis
running. It also makes sense if you consider that each SPN can be associated with only one security
principal. Therefore, if a web application is load balanced across several servers, the application pool
account is constant across all servers; therefore, it must have the SPN.
For each web application, you should assign two SPNsone with the fully qualified domain name for the
service, and one with the NetBIOS name of the service; this is why the intranet web application pool
account should be assigned an SPN of HTTP/intranet.
Note: In many environments, a single application pool may be used by multiple web
applications. The application pool account should be given a pair of SPNs for each of its web
applications that use Kerberos authentication.
You can configure SPNs using a variety of Windows utilities and applications, including ADSI Edit and
SetSPN.exe.
Configuring SPN for a service or application pool account by using ADSI Edit
To configure an SPN for a service or application pool account, you must have domain administrative
permissions or a delegation to modify the servicePrincipalName property. To configure service principal
names for a service or application pool account using ADSI Edit, perform the following steps:
1.
Start ADSI Edit.
2.
In the console tree, right-click ADSI Edit, and then click Connect To.
The Connection Settings dialog box appears.
3.
Click OK.
4.
In the console tree, expand Default naming context, expand the domain, and then expand the
nodes representing the organizational unit (OU) in which the account exists. Click the OU in which the
account exists.
5.
In the details pane, right-click the service or application pool account, and then click Properties.
The Properties dialog box appears.
6.
In the Attributes list, double-click servicePrincipalName.

The Multi-Valued String Editor dialog box appears.
7.
In the Value to Add field, type the SPN, and then click Add.
Repeat Step 7 for additional SPNs. Remember that an application pool account should have two SPNs, in
the form HTTP/site.domain.com and HTTP/site, for each web application that uses Kerberos
authentication in the application pool. Remember also to add the port number if the site runs on a port
other than port 80, for example, HTTP/site.litwareinc.com:9999 and HTTP/site:9999.
8.
Click OK twice.
Configuring SPNs for a service or application pool account by using SetSPN

You can also use the command line tool SetSPN.exe to add SPNs to an account.
The following example adds the SPNs for the intranet web application to the application pool account.
Adding SPNs by using SetSPN
setspn LITWARE\SP_Service a HTTP/intranet.litwareinc.com
setspn LITWARE\SP_Service a HTTP/intranet
Note: For more information about syntax and command line options, run the setspn.exe
/? command.
Configuring SPNs for SQL Server
To configure Kerberos authentication for SQL Server, you will need to add SPNs for the SQL Server service
account. By default, SQL Server communication is over port 1433; therefore, the two SPNs for a SQL Server
running on a server named SQLSERVER01 would be the following:
MSSQLSvc/sqlserver01:1433
MSSQLSvc/sqlserver01.litwareinc.com:1433
Reference Links: For more information about Kerberos authentication in SharePoint 2013,
see:
9-13
Plan for Kerberos authentication in SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299636
Kerberos Survival Guide at http://go.microsoft.com/fwlink/?Linkid=299637 .
Kerberos Authentication How it works! at http://go.microsoft.com/fwlink/?Linkid=299638
Microsoft Kerberos at http://go.microsoft.com/fwlink/?Linkid=299639
Web Application Zones

SharePoint web application zones enable you to
provide alternative logical paths to a SharePoint
web application. Each web application zone
corresponds to an IIS website. By default, a
SharePoint web application includes a single zone
named Default. You can extend a SharePoint web
application to the following additional zones:
Intranet
Internet
Extranet
Custom
When you extend a web application to a new zone, SharePoint creates a new IIS website for the zone. You
can configure each IIS website independently to support the host names, protocols, and authentication
mechanisms you require.
Note: Zone names exist only to distinguish between the zones associated with a web
application. Zone names are not associated with any predetermined configuration settings.
In previous versions of SharePoint, web application zones were the primary way of enabling users to
access sites through different authentication mechanisms. For example, you might have configured the
Default zone to support integrated Windows authentication, and then added an Extranet zone
configured for forms-based authentication to enable partner organizations to access your content.
However, the advent of claims-based authentication means that this approach is redundant in many
scenarios. This is because you can configure multiple claims providers for web applications that use
claims-based authentication, without extending the web application to additional zones. For example, you
could configure the Default zone to support both Integrated Windows authentication and an ASP.NET
membership provider.
SharePoint 2013 also introduces the ability to associate multiple URLs with host-named site collections by
using the Set-SPSiteUrl Windows PowerShell cmdlet. This feature primarily exists to provide a simpler
alternative to Alternate Access Mappings (AAM), but it can also reduce the need to extend your web
application to more than one zone. If you simply need to provide multiple paths to the same content,
host-named site collections offer a better solution, for several reasons:
They create less overhead on the web servers, because an additional IIS website is not required.
They provide more flexibility, because you can provide alternative access to individual site collections
instead of entire web applications.
They enable you to add as many alternative URLs as you need, instead of being constrained to the
five predefined zones.
Extending a web application by using Central Administration
You can use the following procedure to extend a web application to a new zone in Central Administration:
1.
Launch the SharePoint 2013 Central Administration website.
2.
3.
Select the web application you want to extend, and then on the ribbon, on the Web Applications
tab, click Extend.
4.
In the Extend Web Application to Another IIS Web Site dialog box, enter the settings for the new
IIS website.
5.
In the Zone drop-down box, select the name you want to assign to the new zone, and then click OK.
Extending a web application by using Windows PowerShell
You can use the New-SPWebApplicationExtension cmdlet in Windows PowerShell to extend a claimsbased web application to a new zone. The New-SPWebApplicationExtension cmdlet enables you to
specify a name for the new IIS website, a host header, a zone name, a URL, a port, and an authentication
provider to associate with the new zone.
The following example shows how to create a new zone for an existing SharePoint web application.
Extending a SharePoint web application to a new zone
Get-SPWebApplication Identity http://litwareinc.com | New-SPWebApplicationExtension
Name "Litware Intranet" HostHeader "extranet.litwareinc.com" Zone Extranet URL
"https://20331B-NYC-WEB"
Reference Links: For more information about extending web applications, see Extend
claims-based web applications in SharePoint 2013 at
Discussion: Extending Web Applications to Additional Zones

Considering that creating host-named site
collections is now preferred to extending web
applications to additional zones where possible,
when might it still be appropriate to extend web
applications to additional zones?
9-15
Lesson 2
Configuring Federated Authentication
Federated authentication provides a unified approach to combining credentials in a heterogeneous

environment, where multiple methods for authentication exist and different authentication providers play
a role.
This lesson explains the concepts behind federated identity and describes how you can enable users with
different credentials to access your SharePoint deployment.
Lesson Objectives
Explain the concepts behind federated identity.
Explain how SharePoint manages and normalizes identities from different providers.
Configure forms-based authentication for SharePoint 2013.
Explain how SAML tokenbased authentication works in SharePoint 2013.
Configure SharePoint 2013 to use an AD FS deployment as a trusted authentication provider.
Overview of Federated Identity

An organization that uses federated
authentication allows people to use third-party
credentialsin other words, credentials that are
managed by an identity management system
outside of the organizationto access its
application. For example, you can allow users from
a partner organization to log on with their own
domain credentials by configuring a trust
relationship with the partner organization's AD FS
deployment. Alternatively, you could configure
your application to allow users to log on using
credentials from a public identity management
system, such as Windows Live ID.
Using federated authentication in this way offers the following advantages:
Infrastructure overhead is reduced by delegating identity management to a third party.
Users can access multiple systems with a single set of credentials.
When you use claims-based authentication, you can associate multiple authentication providers with a
single SharePoint web application. For example, you can allow users to log on to your SharePoint sites
using either local Windows credentials, credentials from a trusted partner organization, or a Windows Live
ID. Therefore, you no longer need to create multiple web application zones to support multiple
authentication methods.
Claims providers
Because claims-based authentication is governed by open standards, you can configure SharePoint 2013
to trust credentials from a wide range of identity management systems. For example, you can use
federated identities from AD FS or Azure Access Control Services (ACS), together with a range of public
9-17
and third-party identity management systems, such as Windows Live ID, OpenID, and Facebook. To
support federated identity, the claims provider must implement various industry standard specifications:
WS-Federation. This specifies the architecture for a clean separation between trust mechanisms,
security token formats, and the protocols for obtaining tokens.
WS-Trust. This specifies how to request and receive security tokens.
SAML. This is an XML vocabulary for describing claims in an interoperable security token.
To support claims-based identity federation, claims providers must perform a range of tasks, including:
Verifying the identity of the user.
Performing claims augmentation, which means adding additional information about the user, such as
email addresses or role memberships.
Constructing and issuing a SAML-based security token containing the user claims.
Trust relationships
When you consume federated identities, you do not have access to any information about the user.
Instead, you trust the claims provider to provide accurate information. For this process to work, you must
establish a trust relationship between the claims provider and a relying party. For example, if SharePoint
receives a claim that a user is a member of the Financial Auditors role, you have no way of independently
verifying that claim. You will trust the claim only if you trust the claims provider that issued the claim.
Typically, trust relationships are established by exchanging security certificates with the claims provider.
The claims provider encrypts and signs the SAML security tokens to enable relying parties to verify that
the claims originate from a trusted source.
Claims Authentication Process and Normalization

When a user signs in to an application using a
federated identity, the application first redirects
the user to the issuing authority, or claims
provider. The issuing authority authenticates the
user and generates a SAML security token
containing claims about the user. The user is then
redirected back to the application and presents
the SAML token, along with the users request. The
application can use the claims in the SAML token
to make decisions about what the user is
authorized to do.
A key element in all claims-based systems is trust.

An issuing authority can claim many things about a user, but you have to determine whether your systems
trust the claims made by the issuing authority. Advanced claims-based authentication systems may pull
claims from more than one system and aggregate them together to make an authorization decision.
The following steps describe the federated sign-in process for a user to perform an action that requires
authentication:
1.
As a user, you request access to the SharePoint site you are interested in visiting.
2.
The SharePoint site redirects you to the issuing authority, for example an AD FS web service.
3.
The issuing authority prompts you for credentials and attempts to authenticate you.
4.
If the issuing authority is able to authenticate you, the issuing authority's IP-STS generates a SAML
token containing a set of claims about you.
5.
The SAML token is forwarded to SharePoint, along with your original request.
6.
SharePoint uses the token to authorize you for the actions requested.
For example, most Microsoft sites require you to have a Windows Live ID to log on. When you log on, you
are redirected to Windows Live ID, where you are prompted for credentials. You are then redirected to the
website with claims data, such as a token. The site then uses that token to allow you to access its
resources.
SharePoint identity normalization
When you use Windows classic-mode authentication, SharePoint receives a WindowsIdentity object that
represents an authenticated user. SharePoint translates the WindowsIdentity object into an SPUser
object, and then uses the SPUser object to determine access to resources. By contrast, when you use
claims-based authentication, all identities are first converted into ClaimsIdentity objects in a process
known as identity normalization. These ClaimsIdentity objects are then translated into SPUser objects,
which are used to determine access to resources as before. In this way, claims-based identities are
converted into valid and recognized SharePoint users, regardless of the initial authentication mechanism.
Claims to Windows Token Service (C2WTS)

The claims-based identities used by SharePoint cannot be used to access resources that require a
Windows security token for authentication, such as SQL Server databases. Instead, the claims-based
identity must first be converted back into a Windows security token. SharePoint relies on the Claims to
Windows Token Service (C2WTS) to perform this conversion.
The C2WTS is a Windows service that is installed as part of the Windows Identity Foundation (WIF). It
extracts User Principal Names (UPNs) from non-Windowsbased security tokens, such as SAML-based
claims tokens. For calls that require SharePoint to impersonate a Windows user to succeed, you must:
Manually start the C2WTS service on each web front-end server in the SharePoint farm.
Configure the list of allowed callers to C2WTS to include the WSS_WPG SharePoint security group.
Reference Links: For detailed information about how to configure the C2WTS, see Claims
to Windows Token Service (C2WTS) at http://go.microsoft.com/fwlink/?Linkid=299642
Configuring Forms-Based Authentication for SharePoint 2013

Forms-based authentication describes an
approach to authenticating the users of an
ASP.NET web application. When you use formsbased authentication, unauthenticated users are
redirected to a logon page (the logon form) where
they can enter their credentials. An ASP.NET
membership provider authenticates the user
against an identity store, and an ASP.NET role
provider (or role manager) retrieves information
about the role memberships of the user. You can
use a variety of identity stores with forms-based
authentication, including any Lightweight
Directory Access Protocol (LDAP) compatible directory, SQL Server databases, or custom stores.
Unlike earlier versions of forms-based authentication, ASP.NET membership providers now issue claimsbased identities. To use forms-based authentication, you must create your SharePoint web application in
claims-based authentication mode, not Windows classic-mode.
Configuring membership providers and role managers
ASP.NET membership providers and role providers are registered and configured in the Web.config file
for the application or service that uses forms-based authenticationin this case, the SharePoint web
application.
The following example shows how a membership provider and a role manager are configured to access
an LDAP directory in a Web.config file.
Defining membership providers and role managers
<membership>
<providers>
<add name="membership"
type="Microsoft.Office.Server.Security.LdapMembershipProvider,
Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c"
server="litwareinc.com"
port="389"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="samAccountName"
userContainer="OU=UserAccounts,DC=litwareinc,DC=com"
userObjectClass="person"
userFilter="(&(ObjectClass=person))"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" />
</providers>
</membership>
<roleManager enabled="true">
<providers>
<add name="rolemanager"
type="Microsoft.Office.Server.Security.LdapRoleProvider,
Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c"
server="litwareinc.com"
port="389"
useSSL="false"
groupContainer=" DC=litwareinc,DC=com"
groupNameAttribute="cn"
groupNameAlternateSearchAttribute="samAccountName"
groupMemberAttribute="member"
userNameAttribute="samAccountName"
dnAttribute="distinguishedName"
groupFilter="(&(ObjectClass=group))"
userFilter="(&(ObjectClass=person))"
scope="Subtree" />
</providers>
</roleManager>
To use forms-based authentication in a SharePoint web application, you need to register your
membership provider and role manager in three configuration files:
The Web.config file for the Central Administration website. This enables Central Administration to
recognize your membership provider and role manager as trusted providers.
The Web.config file for the Security Token Service Application. This enables the Security Token
Service to issue security tokens for users who were authenticated through your membership provider.
The Web.config file for the SharePoint web application. This is the actual ASP.NET web application
that will use your membership provider for authentication and claims augmentation.
Reference Links: For more information about configuring forms-based authentication for
SharePoint 2013, see:
Plan for user authentication methods in SharePoint 2013 at

Configure forms-based authentication for a claims-based web application in SharePoint 2013 at

Discussion: Configuring Claims-Aware Form-Based Authentication

If you have used earlier versions of forms-based
authentication, how does the configuration
process for this claims-aware forms-based
authentication differ?
Understanding SAML Token-Based

Authentication
You can configure SharePoint 2013 to use SAML
token-based federated authentication from a wide
range of claims providers. SharePoint uses the
following industry standards to request, receive,
and process SAML tokens:
SAML 1.1 protocol
WS-Federation Passive Requestor Profile (WSF PRP)
If the claims provider supports these standards

like many open authentication platforms and
federation gateways doyou should be able to
federate authentication to your SharePoint 2013 deployment.
At a high level, you will need to perform the following steps to use SAML token-based authentication with
a SharePoint web application:
1.
Register your web application with the claims provider as a relying party.
2.
Configure rules on the claims provider, to determine what claims should be presented to the relying
party and how user attributes should be mapped to claims.
3.
Configure a trust relationship between the SharePoint Security Token Service and the claims provider.
This is accomplished by exporting a token signing certificate from the claims provider, and then using
the exported certificate to create a new trusted root certification authority on the SharePoint server.
4.
Register a new RP-STS entry for the claims provider in the SharePoint Security Token Service. This
should specify:
o
A name and description for the claims provider.
5.
The certificate to use to verify and decrypt SAML tokens.
How incoming claim types should be mapped to outgoing claim types.
The remote sign-in URL for federated identities.
The supplied claim that uniquely identifies the user.
Configure a web application to use the claims provider by selecting the claims provider from the list
of configured authentication providers in the authentication settings for the web application zone.
After you complete these steps, the SharePoint Security Token Service acts as an RP-STS for the claims
provider. When the claims provider issues a SAML security token to SharePoint, the RP-STS will verify the
token, parse the claims, and issue a local security token that SharePoint can use to establish the level of
access that should be granted to the user.
Active Directory Federation Services (AD FS)
AD FS is a component of the Windows Server platform that provides identity federation services. In claims
terminology, AD FS is an issuing authority and an IP-STS. AD FS 2.0 enables you to federate identities from
a wide range of authentication providers (or attribute stores in AD FS terminology), including:
Active Directory Domain Services (AD DS)
SQL Server
Custom authentication providers
AD FS supports industry standards for claims authentication, including SAML 1.1 and WS-F PRP. An AD FS
deployment includes a web service that exposes an endpoint for federated authentication. Relying parties,
such as a SharePoint web application, can redirect unauthenticated users to the remote AD FS endpoint.
AD FS will then authenticate the user, perform claims augmentation, and issue a SAML security token that
the user can present to SharePoint, along with the users request.
One common use scenario for AD FS is to federate identities from a local AD DS implementation. You can
then enable other organizations to configure a trust relationship with your AD FS deployment through the
exchange of certificates. This allows your user to access resources at the partner organization by using his
or her local domain credentials. When your user attempts to access the remote resource, he or she is
redirected to your AD FS web service and authenticated. Your AD FS service then issues a SAML-based
security token containing claims about the user. The remote relying party can examine these claims and
allow access to resources based on user name, role memberships, or other criteria.
For example, suppose you manage a SharePoint 2013 deployment at Litware, Inc. Your organization is
collaborating with a company named Northwind Traders on a variety of projects, and you need to give
Northwind Traders employees access to your SharePoint sites. Instead of creating local AD DS accounts
for Northwind Traders employees, you work with the IT team at Northwind Traders to configure a trust
relationship with their AD FS deployment. By taking this approach, you can enable Northwind Traders
employees to log on to your SharePoint sites using their Northwind domain credentials.
Windows Azure Access Control Services (ACS)
Windows Azure Access Control Services (ACS) 2.0 is a cloud-based service that provides identity
federation services. ACS is able to federate and transform identities from a wide range of standards-based
identity providers. These include on-premise directories such as AD DS, in addition to a range of web
identity providers such as Windows Live ID, Facebook, Yahoo!, and Google.
Because ACS 2.0 is a SAML token-based identity provider, you can use ACS as an authentication provider
for your SharePoint 2013 deployments. At a high level, you must complete the following tasks to use ACS
as an authentication provider:
1.
Register your SharePoint web application as a relying party with ACS.
2.
Configure claim rules in ACS to specify the identity store you want to use and the user attributes you
want to send to SharePoint as claims.
3.
Create a trusted authentication provider in SharePoint to represent ACS.
4.
Configure a SharePoint web application to use the trusted authentication provider.
Reference Links: For more information and resources about ACS, see Access Control
Service 2.0 at http://go.microsoft.com/fwlink/?Linkid=299644
Configuring SAML Token-Based Authentication with AD FS

To configure a SharePoint 2013 web application to
use federated identities from a remote AD FS
deployment, you need to perform the following
tasks:
1.
Configure the remote AD FS deployment to

include your SharePoint web application as a
relying party.
2.
Configure your SharePoint deployment to

trust the remote AD FS deployment as an
identity provider.
3.
Configure your SharePoint web application to use the trusted AD FS deployment for authentication.
The following sections provide more information on each of these tasks.
Task 1 - Configure the remote AD FS deployment
To configure AD FS to act as an IP-STS for a SharePoint 2013 web application, you must register the web
application with AD FS as a relying party. You must also configure a claim rule that specifies the attributes
that AD FS should send to SharePoint as claims. Finally, you must export the token-signing certificate so
that the SharePoint administrator can use the certificate to configure a trust relationship with AD FS.
Register the SharePoint web application as a relying party

1.
You can use the following procedure to register your SharePoint web application with AD FS as a
relying party. You must be a member of the local Administrators group on the AD FS server to
perform these steps. On the AD FS server, open the Active Directory Federation Services (AD FS) 2.0
Management console.
2.
In the navigation pane, expand Trust Relationships, and then double-click Relying Party Trusts.
3.
In the right pane, click Add Relying Party Trust.

This launches the Active Directory Federation Services (AD FS) 2.0 configuration wizard.
4.
On the Welcome to the Add Relying Party Trust Wizard page, click Start.
5.
Select Enter data about the relying party manually, and then click Next.
6.
Type a name for the relying party, and then click Next.
7.
Ensure that Active Directory Federation Services (AD FS) 2.0 Profile is selected, and then click
Next.
8.
Do not use an encryption certificate. Click Next.
9.
Select Enable support for the WS-Federation Passive protocol.
10. In the WS-Federation Passive protocol URL field, type the URL of the SharePoint web application,
and append /_trust/ (for example, https://litwareinc.com/_trust/). Click Next.
Note: The web application URL must use the HTTPS protocol. If necessary, extend your web
application to an additional zone to provide a Secure Sockets Layer (SSL) connection.
11. Type a name for the relying party trust identifier in Uniform Resource Name (URN) format (for
example, urn:sharepoint:litwareinc.com), click Add, and then click Next.
Note: You will specify this value as the realm when you configure a trusted identity token
issuer in SharePoint.
12. Select Permit all users to access this relying party, and then click Next.
13. On the Ready to Add Trust page, click Next.
14. On the Finish page, click Close.
This opens the Rules Editor Management console. Leave the console open; you will use it to configure a
claim rule in the next stage of the process.
Configure a claim rule
Now that you have registered your web application as a relying party, you need to tell AD FS what
identity store to use and which attributes to send to SharePoint as claims. You do this by configuring a
claim rule. The following example assumes that you will use the local Active Directory deployment as the
identity store.
1.
In the Rules Editor Management console, on the Issuance Transform Rules tab, click Add Rule.
2.
On the Select Rule Template page, select Send LDAP Attributes as Claims, and then click Next.
3.
On the Configure Rule page, type a name for the claim rule in the Claim rule name field.
4.
In the Attribute Store drop-down list, click Active Directory.
5.
In the Mapping of LDAP attributes to outgoing claim types section, under LDAP Attribute, select
SAM-Account-Name.
6.
Under Outgoing Claim Type, select E-Mail Address.
7.
Under LDAP Attribute, select User-Principal-Name.
8.
Under Outgoing Claim Type, select UPN.
9.
Click Finish, and then click OK.
Export the token-signing certificate
Your final task on the AD FS server is to export the token-signing certificate. You will need to provide this
certificate to the administrator of the SharePoint 2013 deployment, who will use the certificate to
configure a trust relationship with AD FS.
1.
On the AD FS server, open the Active Directory Federation Services (AD FS) 2.0 Management console.
2.
In the navigation pane, expand Service, and then click Certificates.
3.
Under Token signing, click the primary token certificate as indicated in the Primary column.
4.
In the right pane, click View Certificate link.

This displays the properties of the certificate.
5.
Click the Details tab, and then click Copy to File.
6.
On the Welcome to the Certificate Export Wizard page, click Next.
7.
On the Export Private Key page, click No, do not export the private key, and then click Next.
8.
On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next.
9.
On the File to Export page, type a file path and name for the exported certificate (for example,
C:\NorthwindADFS.cer), and then click Next.
10. On the Completing the Certificate Export Wizard page, click Finish.
After completing this process, you must make the certificate available to the administrator of the
SharePoint 2013 deployment. The SharePoint administrator will need to copy the certificate on to the
SharePoint server to configure a trust relationship.
Note: If your token-signing certificate is not a root certificate, you must also export every
certificate in the certification chain. The SharePoint administrator will need to configure a trusted
certification authority for every certificate in the chain.
Task 2 - Configure SharePoint to trust AD FS as an identity provider
To configure a trust relationship between SharePoint 2013 and an AD FS deployment, you need to
register the AD FS with SharePoint as a trusted authentication provider. In claims terminology, this process
essentially creates an RP-STS for the AD FS deployment within the SharePoint Security Token Service
application. However, before you can do this, you must register a trusted certification authority for the
token signing certificate and for any parent certificates in the certification chain.
To complete the following procedures, you must be:
A member of the securityadmin server role on the SQL Server instance.
A member of the db_owner database role on the configuration database, the content database for
the Central Administration web application, and the content database(s) for the web application that
will use AD FS federated authentication.
A member of the local Administrators group on the SharePoint server.
Import the token-signing certificate

1.
On a SharePoint server, start the SharePoint 2013 Management Shell.
2.
At the command prompt, create an object to represent the token signing certificate that was
exported from AD FS (update the file path to the certificate as required).
$cert = New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2("C:\NorthwindADFS.cer"
)
3.
At the command prompt, import the certificate as a trusted SharePoint root authority.
New-SPTrustedRootAuthority Name "Litware Token Signing Cert" Certificate $cert
Leave the SharePoint 2013 Management Shell window open, because you will use the variables you have
created in the procedures that follow. If the token signing certificate is part of a certification chain, you
must perform this procedure for every certificate in the chain. Start with the root certificate and work your
way down to the token signing certificate.
The next task is to define claim mappings. For each claim that AD FS provides, you need to tell SharePoint
how to map it to a claim that it can use locally.
Define Claim Mappings

1.
Create a claim mapping for the email address claim.

$emailClaimMapping = New-SPClaimTypeMapping -IncomingClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
-IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
2.
Create a claim mapping for the UPN claim.

$upnClaimMapping = New-SPClaimTypeMapping -IncomingClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
-IncomingClaimTypeDisplayName "UPN" -SameAsIncoming
Leave the SharePoint 2013 Management Shell window open, because you will use the variables you have
created in the procedures that follow. Repeat this procedure for every claim that the AD FS server
provides.
You now have enough information to create a new trusted authentication provider. This process
configures an RP-STS for the AD FS instance in the SharePoint Security Token Service Application. It also
makes the AD FS instance selectable as a trusted authentication provider when you configure a web
application in Central Administration.
Configure a trusted authentication provider

1.
Define a value for the realm. This should be the value you provided as the relying party trust
identifier when you configured AD FS.
$realm = "urn:sharepoint:litwareinc.com"
2.
Define a value for the sign-in URL of the AD FS server. Typically, this is in the form https://[server
name]/adfs/ls.
$signInURL = "https://adfs.northwindtraders.com/adfs/ls"
3.
Create a trusted authentication provider, by specifying:

o
A name for the provider. This defines how the authentication provider is named when you
configure a web application in Central Administration.
A description for the provider. This appears alongside the name of the authentication provider
when you configure a web application in Central Administration.
The realm value.
The sign-in URL.
The token signing certificate.
The claims mappings you defined in the previous procedure.
The identifier claim that uniquely identifies federated users.
New-SPTrustedIdentityTokenIssuer -Name "Northwind Traders AD FS" -Description "AD FS

at Northwind Traders for identity federation" -realm $realm -ImportTrustCertificate
$cert -ClaimsMappings $emailClaimMapping,$upnClaimMapping -SignInUrl $signInURL IdentifierClaim $emailClaimMapping.InputClaimType
At this stage, SharePoint is fully configured to trust the remote AD FS deployment as an identity provider.
You can now configure individual web application to use the AD FS deployment for authentication.
Task 3 - Configure a SharePoint Web Application to use a trusted AD FS identity

provider
After you configure a trusted authentication provider for AD FS in SharePoint, you can select the AD FS
instance from a list of trusted authentication providers when you configure a web application in Central
Administration. When you create a new web application, you are prompted to select authentication
providers as part of the configuration process. If your web application already exists, you can use the
following procedure to add AD FS to the authentication providers for the web application:
1.
On the Central Administration website, on the Application Management page, click Manage web
applications.
2.
Click the web application you want to configure, and then on the ribbon, click Authentication
Providers.
3.
Under Zone, click the name of the zone you want to configure (for example, Default).
4.
On the Edit Authentication page, in the Claims Authentication Types section, select Trusted
Identity Provider, and then select the AD FS provider name you configured in the previous
procedure.
5.
Click OK.
If your web application is configured with multiple authentication providersfor example, local Windows
claims-mode sign-in and federated AD FS sign inusers will be redirected to a Sign In page and
prompted to select an authentication method when they browse to a site within the web application.
Reference Links: For more information about configuring SAML token-based
authentication for SharePoint 2013, see:
Plan for user authentication methods in SharePoint 2013 at

Configure SAML-based claims authentication with AD FS in SharePoint 2013 at

Discussion: Advantages of Using Federated Identity Providers

What are the main advantages of using federated
identity providers?
Lesson 3
Configuring Server-to-Server Authentication
9-27
Many features in SharePoint rely on the secure exchange of data between a SharePoint server farm and
other server platforms, such as Exchange Server, Lync Server, and other SharePoint server farms. In each
case, a server must be able to verify that the other server is trusted to request information on behalf of a
user. This process is known as server-to-server authentication.
In this lesson, you will learn how server-to-server authentication works in SharePoint 2013, and you will
learn how to configure trust relationships between SharePoint and other server platforms.
Lesson Objectives
Explain how server-to-server authentication works.
Configure a trust relationship between SharePoint 2013 and Exchange Server 2013.
Configure a trust relationship between SharePoint 2013 and Lync Server 2013.
Configure a trust relationship between two SharePoint 2013 server farms.
Describe the user profile requirements for server-to-server authentication.
Understanding Server-to-Server Authentication

Many of the features in SharePoint 2013 rely on
the sharing of information between a SharePoint
server farm and other server platforms. These
platforms can include the following:
Office Web Apps Server 2013. This provides

browser-based viewing and editing of
Microsoft Office documents that are stored in
SharePoint sites.
Exchange Server 2013. Many records

management and project management
features in SharePoint rely on integration with
Exchange.
Lync Server 2013. SharePoint 2013 provides close integration with Lync Server for presence
information, and enables users to connect with colleagues from the SharePoint user interface.
Azure Workflow Server. Workflows in SharePoint 2013 rely on the Windows Azure workflow engine.
The Windows Azure Workflow Manager component may be external to the SharePoint server farm.
Other SharePoint Server Farms. In some cases, you will want to share SharePoint service
applications across multiple SharePoint server farms.
In each of these scenarios, the process relies on a trust relationship between the SharePoint server farm
and the external server platform. After you configure a trust relationship, the server platforms use a
protocol based on the OAuth 2.0 standard to provide authorized access to resources.
Trust relationships
When you plan for trust relationships between server platforms, you must consider the direction of the
trust relationship. From the perspective of your SharePoint deployment, trust relationships can be
incoming or outgoing:
Incoming trust scenario. If your Exchange Server deployment requests data from your SharePoint
Server deployment, this is an incoming trust scenario. To use this scenario, you must configure the
SharePoint deployment to trust the Exchange deployment.
Outgoing trust scenario. If your SharePoint Server deployment requests data from your Exchange
Server deployment, this is an outgoing trust scenario. To use this scenario, you must configure the
Exchange deployment to trust the SharePoint deployment.
In essence, trust relationships are always unidirectional. On each participating server platform, you
configure trust relationships only to support incoming requests. If two server platforms both request data
from each other, you configure a trust relationship to support incoming requests on each server platform.
You can configure a trust relationship in two ways:
Certificate exchange. You can export the token signing certificate from the server you want to trust,
import the certificate onto the server that will serve incoming server-to-server requests, and use the
certificate to register the server you want to trust as a trusted security token issuer.
JSON metadata endpoint. SharePoint 2013 and Exchange 2013 expose a JavaScript Object Notation
(JSON) metadata endpoint. This endpoint provides an identifier for the server's STS, together with a
serialized version of the token signing certificate. You can use this endpoint to register a trusted
security token issuer without manually exporting and importing the certificate.
Note: If your server platforms are part of an Office 365 tenancy, there are no additional
configuration tasks required to use features that depend on server-to-server authentication.
OAuth 2.0
OAuth 2.0 is an open standard for authorization. OAuth is designed to enable users to provide third
parties with access to their resources without sharing their credentials. Instead of credentials, an OAuth
access token is issued to the third party. The token grants access to a specific resource, on a specific site,
for a defined duration (for example, 30 minutes), on behalf of a specific user. The Microsoft server-toserver protocol relies on OAuth to share information across server platforms.
For example, suppose a user creates an eDiscovery case in SharePoint. The purpose of the eDiscovery case
is to identify content, both in SharePoint sites and Exchange mailboxes, which must be preserved as part
of a legal hold. In this case, the Exchange server will issue an OAuth token that grants the SharePoint
server access to the required mailboxes for a fixed period of time. In the same way, workflows hosted on
Windows Azure Workflow Server must be able to retrieve data from SharePoint. The SharePoint server will
issue an OAuth token that grants the Windows Azure Workflow Server access to the requested SharePoint
content for a fixed period of time.
It is important to understand that OAuth tokens are issued on behalf of users. When a user action results
in a server-to-server request, the user is effectively authorizing SharePoint to issue an OAuth token on his
or her behalf.
9-29
Configuring a Trust Relationship between SharePoint 2013 and Exchange

Server 2013
Many SharePoint 2013 features rely on trust
relationships between SharePoint 2013 and
Exchange Server 2013. For example, the task
aggregation functionality, where users can access
SharePoint tasks from their Exchange mailboxes,
relies on SharePoint trusting the Exchange server
to retrieve data on behalf of users. The records
management and eDiscovery functionality, where
users can create legal holds on SharePoint content
and Exchange mailboxes, relies on the Exchange
server trusting SharePoint to retrieve data on
behalf of users.
To configure trust relationships between SharePoint 2013 and Exchange Server 2013, you must complete
three high-level tasks:
1.
Configure your SharePoint 2013 deployment to trust your Exchange Server 2013 deployment.
2.
Assign permissions to the SharePoint application principal that represents your Exchange Server 2013
deployment.
3.
Configure your Exchange Server 2013 deployment to trust your SharePoint 2013 deployment.
Task 1 - Configure SharePoint to trust Exchange Server
To configure a trust relationship with another server platform in SharePoint, you use the NewSPTrustedSecurityTokenIssuer cmdlet. This essentially creates a trust relationship between the STS on
the external server platform and the SharePoint STS, where the external server is the identity provider (in
other words, the IP-STS) and SharePoint is the relying party (the RP-STS).
The OAuth-based server-to-server protocol uses JavaScript Object Notation (JSON) to exchange data, so
you must specify the JSON metadata endpoint of the remote server when you configure the trust
relationship. Typically, this is in the form https://<HostName>/metadata/json/1, where <HostName> is
the name or host header of the Exchange Server.
To create the trust relationship, in the SharePoint 2013 Management Shell, run the following command.
Creating a trust relationship with an Exchange Server deployment
New-SPTrustedSecurityTokenIssuer MetadataEndpoint "https://<HostName>/metadata/json/1"

IsTrustBroker Name "<FriendlyName>"
In this example:
<HostName> is the name or host header of the Exchange Server.
<FriendlyName> is the friendly name you want to use to identify the Exchange Server.
Task 2 - Configure permissions for Exchange access to SharePoint
Now that you have configured a trust relationship with the Exchange Server, you must grant permissions
to the application principal that represents the Exchange Server. An application principal is an SPUser
object that represents a non-SharePoint applicationin this case, Exchange Serverthat accesses data on
SharePoint. Your SharePoint deployment must be able to grant the Exchange Server any permissions held
by the user that Exchange is representing. To facilitate this, you must grant the application principal full
control over relevant SharePoint sites.
To assign permissions to the application principal, in the SharePoint 2013 Management Shell, run the
following commands.
Assigning permissions to an application principal for Exchange Server
$exchange=Get-SPTrustedSecurityTokenIssuer Identity "<FriendlyName>"
$app=Get-SPAppPrincipal -Site http://<HostName> -NameIdentifier $exchange.NameId
$site=Get-SPSite http://<HostName>
Set-SPAppPrincipalPermission AppPrincipal $app Site $site.RootWeb Scope
sitesubscription Right fullcontrol -EnableApplyOnlyPolicy
In this example:
<FriendlyName> is the friendly name you applied to the Exchange Server when you configured the
trust relationship.
<HostName> is the host name of the SharePoint site that you want the Exchange Server to access.
Task 3 - Configure Exchange Server to trust SharePoint
By configuring SharePoint to trust Exchange Server, you have enabled the Exchange Server to retrieve
data from SharePoint on behalf of users. This supports scenarios such as task aggregation, where tasks
from a SharePoint site are aggregated to users Exchange mailboxes. However, scenarios such as
eDiscovery rely on SharePoint being able to retrieve data from Exchange. To support these scenarios, you
must also configure your Exchange server to trust your SharePoint deployment.
You can use the following procedure to configure Exchange Server to trust a SharePoint deployment:
1.
Log on to an Exchange Server 2013 server and launch the Exchange Management Shell.
2.
At the command prompt, type the following commands.

cd c:\'Program Files'\Microsoft\'Exchange Server'\V15\Scripts
.\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl
https://<HostName>/_layouts/15/metadata/json/1 -ApplicationType SharePoint
In this example, <HostName> is the name and port of any SSL-enabled web application on the
SharePoint deployment.
Reference Links: For more information about configuring trust relationships between
SharePoint 2013 and Exchange Server 2013, see Configure server-to-server authentication
between SharePoint 2013 and Exchange Server 2013 at
9-31
Configuring a Trust Relationship between SharePoint 2013 and Lync Server

2013
The process for configuring trust relationships
between SharePoint and Lync Server is broadly
similar to configuring trust relationships between
SharePoint and Exchange Server. To enable full
integration between SharePoint and Lync Server,
you must complete two high-level tasks:
1.
Configure your SharePoint 2013 deployment

to trust your Lync Server 2013 deployment.
2.
Configure your Lync Server 2013 deployment

to trust your SharePoint 2013 deployment.
Task 1 - Configure SharePoint to trust Lync Server
To configure server-to-server authentication between SharePoint and Lync Server, you must create a trust
relationship between the SharePoint STS (the RP-STS) and the Lync Server STS (the IP-STS). You can use
the following procedure to configure SharePoint to trust Lync Server:
1.
On a SharePoint server, open the SharePoint 2013 Management Shell.
2.
At the command prompt, type the following command.

New-SPTrustedSecurityTokenIssuer MetadataEndpoint
"https://<HostName>/metadata/json/1" IsTrustBroker Name "<FriendlyName>"
In this example:
<HostName> is the name or host header of the Lync server.
<FriendlyName> is the friendly name you want to use to identify the Lync server.
Task 2 - Configure Lync Server to trust SharePoint
To configure Lync Server to trust your SharePoint deployment, you must perform two high-level tasks:
Assign a server-to-server authentication certificate to Lync Server, if a certificate has not been
assigned already.
Configure SharePoint as a partner application on the Lync Server deployment.
These procedures can be complex and require familiarity with the Lync Server platform. They are beyond
the scope of this course. For more information about these procedures, see the following:
Configure server-to-server authentication between SharePoint 2013 and Lync Server 2013 at
Assigning a Server-to-Server Authentication Certificate to Microsoft Lync Server 2013 at

Configuring an On-Premises Partner Application for Microsoft Lync Server 2013 at

Configuring a Trust Relationship Between Two SharePoint 2013 Server

Farms
There are various scenarios in which you might
want to enable communication between two
SharePoint 2013 server farms. For example, you
might want to use one farm as a remote search
index, or you might want to share service
applications across farms.
There are two ways in which you can establish a
trust relationship between SharePoint 2013 server
farms:
By exchanging certificates and creating a trust

relationship based on the remote farm's
token-signing certificate.
By configuring a trust relationship based on the remote farm's OAuth JSON metadata endpoint.
These approaches essentially accomplish the same thing. The JSON metadata endpoint, which is exposed
by every SharePoint site at the relative URL /_layouts/15/metadata/json/1, provides an identifier for the
remote STS, together with a serialized version of the token-signing certificate. As such, you are using the
token-signing certificate to create the trust relationship regardless of which approach you use. In both
cases, you use the New-SPTrustedSecurityTokenIssuer Windows PowerShell cmdlet to configure the
trust relationship. This essentially creates a local RP-STS to communicate with the remote farm's IP-STS.
The New-SPTrustedSecurityTokenIssuer cmdlet enables you to specify either an imported X.509
certificate or a remote metadata endpoint to configure a trust relationship.
You can use the following procedure to configure a trust relationship with a remote SharePoint farm. This
example uses the metadata endpoint approach:
1.
On a SharePoint server, launch the SharePoint 2013 Management Shell.
2.
At the command prompt, type the following command.

New-SPTrustedSecurityTokenIssuer MetadataEndpoint
"https://<HostName>/_layouts/15/metadata/json/1" IsTrustBroker Name
"<FriendlyName>"
In this example:
<HostName> is the name or host header of the remote SharePoint server.
<FriendlyName> is the friendly name you want to use to identify the remote SharePoint server.
Remember that trust relationships are essentially unidirectional, and you configure a trust relationship to
support incoming requests. In many scenariosfor example, when you share service applications with
another farmboth SharePoint farms must trust each other. In these cases, you must perform this
procedure on both server farms to create a two-way trust relationship.
Reference Links: For more information about configuring trust relationships between two
SharePoint 2013 server farms, see:
Configure server-to-server authentication between SharePoint 2013 farms at

Exchange trust certificates between farms in SharePoint 2013 at

Configuring User Profiles to Support Server-to-Server Authentication

When a server platform issues an OAuth token to
another application, the token authorizes the
application to access resources on behalf of a
specific user. As such, when SharePoint receives an
incoming OAuth request, it must be able to
resolve the identity in the request to a specific
SharePoint user. To authorize the request, it must
also be able to determine the set of role claims
that are associated with the user. This process is
known as rehydrating the user's identity.
To enable platforms to resolve user identities,
OAuth tokens include claims for one or more of
the following user attributes:
The Windows Security Identifier (SID)
The AD DS User Principal Name (UPN)
The Simple Mail Transfer Protocol (SMTP) address
The Session Initiation Protocol (SIP) address
9-33
When SharePoint receives an OAuth request, the User Profile service application takes responsibility for
rehydrating the user's identity. The User Profile service application uses the preceding four attributes to
locate the profile of the user. For this process to work, the following conditions must be met:
At least one of these attributes must be up-to-date in user profiles.
User profiles must not contain duplicate attribute values.
You can ensure that these conditions are met by careful planning of user profile synchronization, and by
deleting obsolete user profiles to reduce the likelihood of duplicate values.
Reference Links: For more information about configuring user profiles to support serverto-server authentication, see Server-to-server authentication and user profiles in SharePoint Server
For more information about user profile synchronization, see Plan profile synchronization for
SharePoint Server 2013 at http://go.microsoft.com/fwlink/?Linkid=299758
Discussion: Advantages of Using JSON Metadata Endpoints

What are the advantages of using JSON metadata
endpoints instead of certificate exchange to
establish a trust relationship?
Lab: Configuring SharePoint 2013 to Use Federated

Identities
Scenario
The IT team at Contoso has deployed a SharePoint 2013 intranet site. Members of the CONTOSO domain
are able to access the site using their Windows credentials. The next step is to make the site available to
staff at Contoso Research. Contoso Research currently maintains an entirely separate IT infrastructure, and
the staff are members of a domain named RESEARCH. Your task is to enable Contoso Research staff to
access your SharePoint 2013 intranet site using their RESEARCH domain credentials. To do this, you will
need to register your SharePoint web application as a relying party on the AD FS server at Contoso
Research. Next, you will configure your SharePoint deployment to make the AD FS deployment at
Contoso Research a trusted token issuer. Finally, you will configure the SharePoint web application to use
the AD FS token issuer as an authentication provider.
Objectives
Add a SharePoint web application to AD FS as a relying party.
Configure SharePoint to trust AD FS as an identity provider.
Configure a SharePoint web application to use AD FS as an identity provider.

o
Passw0rd: Pa$$w0rd
Virtual Machine: 20331B-SEA-ADFS-09

o
Password: Pa$$w0rd
Exercise 1: Configuring AD FS to Make the Web Application a Relying

Party
Scenario
In this exercise, you will configure the AD FS deployment at Contoso Research. First, you will register the
SharePoint web application as a relying party. Next, you will configure a claim rule. This claim rule will
specify that AD FS should use AD DS as its identity store for the SharePoint web application, and it will
specify how user attributes from AD DS should be transformed into claims. Finally, you will export the
token-signing certificate so that the SharePoint administrator can use it to create a trust relationship with
your AD FS deployment.
1. Configure a relying party in AD FS
2. Configure a claim rule
3. Export the token-signing certificate
Task 1: Configure a relying party in AD FS
Start the 20331B-SEA-ADFS-09 virtual machine. Wait for the virtual machine to display the logon
screen, and then wait a further five minutes before you proceed to the next step.
Log on to the SEA-ADFS1 virtual machine as RESEARCH\Administrator with password Pa$$w0rd.
Launch AD FS Management.
Add a relying party trust to AD FS with the following properties.

Property
Value
Display name
Contoso SharePoint Intranet
Profile
AD FS profile
Protocol
WS-Federation Passive
WS-Federation Passive protocol URL
https://sharepoint.contoso.com/_trust/
Relying party trust identifier
urn:contoso:sharepoint.contoso.com
Issuance authorization rules
Permit all users to access this relying party
Task 2: Configure a claim rule
In AD FS Management, add a new issuance transform claim rule to the Contoso SharePoint Intranet
relying party trust.
Configure the claim rule to send LDAP attributes as claims.
Name the claim rule Contoso SharePoint Claim Rule.
Configure the claim rule to use Active Directory as the attribute store.
Add the following claim mappings to the rule.

Property
Setting
LDAP Attribute
Outgoing Claim Type
SAM-Account-Name
E-Mail Address
User-Principal-Name
UPN
Task 3: Export the token-signing certificate
In AD FS Management, locate the token-signing certificate for the service.
Export the certificate as an X.509 certificate (.CER file) named ContosoResearchTokenSigning.cer.
Copy the exported certificate to the Share folder on the SharePoint web server.
Results: After completing this exercise, you should have configured AD FS to provide federated
authentication to a SharePoint web application.
Exercise 2: Configuring SharePoint to Trust AD FS as an Identity Provider

Scenario
In this exercise, you will configure the SharePoint 2013 deployment at Contoso to trust the AD FS
deployment at Contoso Research. First, you will use the exported token-signing certificate from Contoso
Research to create a new SharePoint trusted root authority. Next, you will define how incoming claims
from AD FS are mapped to local claims on SharePoint. Finally, you will create a new trusted authentication
provider that configures SharePoint to provide an RP-STS for the AD FS deployment.
1. Import the token-signing certificate
2. Map incoming claims to SharePoint claims
3. Register AD FS as a trusted identity provider in SharePoint
Task 1: Import the token-signing certificate
Log on to the 20331B-NYC-SP-09 virtual machine as Contoso\Administrator with the password

Pa$$w0rd.
Start the SharePoint 2013 Management Shell.
Import the Contoso Research token-signing certificate from the E:\Share folder.
Task 2: Map incoming claims to SharePoint claims
In the SharePoint 2013 Management Shell, create SharePoint claim mappings with the following
properties.
Incoming claim type
Incoming
claim type
display name
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
EmailAddress
Same as
incoming
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
UPN
Same as
incoming
Store the claim mappings as local variables so you can use them in the next task.
Task 3: Register AD FS as a trusted identity provider in SharePoint
Outgoing
claim
type
In the SharePoint 2013 Management Shell window, create a new trusted identity token issuer with the
Property
Value
Name
Contoso Research AD FS
Description
AD FS deployment at Contoso Research
Realm
urn:contoso:sharepoint.contoso.com
Property
Value
Sign-in URL
https://sea-adfs1.contosoresearch.net/adfs/ls
Claims
mappings
The mappings you defined in the previous task
Identifier
claim
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Results: After completing this exercise, you should have configured a SharePoint 2013 deployment to
trust an AD FS deployment as an identity provider.
Exercise 3: Configuring the Web Application to Use the AD FS Identity

Provider
Scenario
In this exercise, you will configure the SharePoint web application that hosts the Contoso intranet to use
the AD FS deployment at Contoso Research as an authentication provider. This will enable team members
at Contoso Research to log on to your intranet with their RESEARCH domain credentials.
1. Configure the web application to use the AD FS identity provider
2. Grant federated users access to the site collection
Task 1: Configure the web application to use the AD FS identity provider
On the 20331B-NYC-SP-09 virtual machine, open the Central Administration website.
Open the authentication settings for the Extranet zone of the sharepoint.contoso.com80 web
application.
Amend the authentication settings to include the Contoso Research AD FS trusted identity provider.
Task 2: Grant federated users access to the site collection
Create a new web application policy for the Extranet zone of the sharepoint.contoso.com80 web
application.
In the web application policy, grant Full Read permissions to all Contoso Research AD FS users.
In Internet Explorer, browse to https://sharepoint.contoso.com.
On the Sign In page, select Contoso Research AD FS.
Log in as RESEARCH\Administrator with the password Pa$$w0rd.
Verify that you have access to the site.
Results: After completing this exercise, you should be able to log on to the SharePoint site at
https://sharepoint.contoso.com with a set of RESEARCH domain credentials.
In this module, you learned how to configure user authentication and server-to-server authentication in
SharePoint 2013.
Review Question(s)
Test Your Knowledge
Question
When is it appropriate to extend a SharePoint web application to additional zones?
When you want to support multiple claims-based identity providers.
When you want to provide access to web application content both over HTTP and
over HTTPS.
When you want to associate multiple host names with a SharePoint site.
When you want to split a web application across multiple content databases.
When you want to enable forms-based authentication.
Test Your Knowledge
Question
Which PowerShell cmdlet should you use to configure SharePoint to trust a SAML
token-based identity provider?
New-SPTrustedIdentityTokenIssuer
New-SPTrustedRootAuthority
New-SPClaimTypeMapping
New-SPClaimsPrincipal
New-SPAuthenticationProvider
Test Your Knowledge

Question
Which SharePoint 2013 service application is responsible for resolving the identity of
the user when SharePoint receives an OAuth-based server-to-server request?
The Security Token Service Application
The Application Management Service Application
The Managed Metadata Service Application
The Business Data Connectivity Service Application
The User Profile Service Application

10-1
Module 10
Securing a SharePoint 2013 Deployment
Contents:
Module Overview
10-1
Lesson 1: Securing the Platform
10-2
10-10
Lesson 2: Configuring Farm-Level Security
10-13
10-24
10-27
Module Overview
Microsoft SharePoint Server 2013 is not just a group of websitesit is also a site-provisioning engine for
intranets, extranets, and Internet sites, a collection of databases, an application platform, and a platform
for collaboration and social features, as well as being many other things. In addition to it touching your
network, it also touches your line-of-business (LOB) applications and Microsoft Active Directory; therefore,
it has a large attack surface to consider and protect. SharePoint 2013 is supplied with several security
features and tools out-of-the-box to help you secure it.
In this module, you will learn how to secure and harden your SharePoint 2013 farm deployment and how
to configure several security settings at the farm level.
Objectives
After completing this module you will be able to:
Secure the SharePoint 2013 platform.
Configure farm-level security in SharePoint 2013.
Lesson 1
Securing the Platform
10-2 Securing a SharePoint 2013 Deployment
In this lesson, you will learn how to secure a SharePoint 2013 platform. Specifically, you will learn how to
plan a secure deployment, harden services and ports on servers, configure non-standard ports for
SharePoint and SQL Server communication, and configure antivirus settings in SharePoint 2013.
Lesson Objectives
Plan a secure deployment of SharePoint 2013.
Harden a SharePoint 2013 server.
Configure ports and protocols in SharePoint 2013.
Configure SharePoint 2013 and SQL Server to communicate using non-standard ports.
Configure antivirus settings in SharePoint 2013.
Planning a Secure Deployment

When planning to secure a SharePoint 2013
environment, you first need to consider the type
of scenario you need to support:
Intranet Scenario. This environment will only

require access within your firewall; therefore,
you only have to be concerned with securing
your resources for internal user access.
Extranet Scenario. This environment will

require you to configure security on your
resources for external and internal user access.
Internet Scenario. This environment will

require you to configure security on your resources for anonymous external user access.
Each of these scenarios has different security requirements, and they also each require different security
measures and technologies.
Defense in depth
Because the majority of organizations store confidential, regulated, or at the very least, sensitive
information on their SharePoint sites, it makes sense that these organizations need to commit to a defense
in depth approach when planning security for their SharePoint farm.
The term defense in depth refers to the use of multilayered security measures to help protect the
information resources or an organization. The term has been borrowed from the military principle that it
is much harder to breach a defense that is complex and has several layers to it than it is to breach a single
barrier.
So, the defense in depth principle for SharePoint requires considering your security at multiple levels of
your infrastructure.
FIGURE 10.1:THE DEFENSE IN DEPTH PRINCIPLE

These are some examples of areas you need to include in your security planning:
10-3
Network. This includes features such as a Threat Management Gateway (TMG) or Unified Access
Gateway (UAG), and network isolation.
Server. This includes steps such as shutting down non-essential services and deleting unnecessary
accounts.
Firewall. This includes blocking ports, opening ports, and reconfiguring default ports and protocols.
Service Accounts. This includes applying least privilege principles to all service accounts, and creating
new application- and service-specific accounts.
Antivirus. This includes ensuring you have a sufficient, compatible, and up-to-date antivirus solution
in place.
Additional Reading: For more information about security hardening for extranets, see
Plan security hardening for extranet environments (SharePoint Server 2010) at
the information remains mostly unchanged.
Hardening a SharePoint Server

Typically, security hardening refers to the process
of securing a system by reducing its surface of
vulnerability, by removing or disabling
unnecessary software. In a SharePoint server farm
environment, individual servers play specific roles,
such as web server, application server, and
database server. Security hardening measures for
these servers depend on the role each server plays.
The primary measure for server hardening is to
shut down non-essential Windows and SharePoint
services.
Web and application server service hardening
Services that use insecure protocols, or that run under accounts with too much privilege are security risks;
therefore, if you do not need them, disable them. When you disable non-essential and unnecessary
services, you rapidly lessen your attack surface and reduce your maintenance overhead.
It is also possible that services running in Windows can be exploited and used by malicious attackers to
obtain access to your system and resources. You should disable all services that your servers and
applications do not require.
To help secure your web and application servers, you should shut down all non-essential services other
than those in the following list.
Ensure that the following services are enabled on your web and application servers:
ASP.NET State Service (if using InfoPath Forms Services or Project Server 2013)
View State service (if using InfoPath Forms Services)
World Wide Web Publishing Service
AppFabric Caching Service
Claims to Windows Token Service
SharePoint Administration
SharePoint Timer service
SharePoint Tracing Service
SharePoint VSS Writer service
Best Practice: You should shut down the SharePoint Administration service when you are
not performing administrative tasks that use administration tools such as SharePoint 2013 Central
Administration and SharePoint 2013 Management Shell.
You should ensure that the following services are enabled on the servers that host the corresponding
roles:
SharePoint User Code Host
SharePoint Search Host Controller
SharePoint Server Search 15
10-5
Forefront Identity Manager service (This service is required by the User Profile service application on
the server that imports profiles from the directory store)
Forefront Identity Manager Synchronization service (This service is required by the User Profile service
application on the server that imports profiles from the directory store)
Additional Reading: For more information about hardening servers in SharePoint 2013,
see Plan security hardening for SharePoint 2013 at
Database server hardening
The key recommendation for SharePoint 2013 is to secure communication between servers in a farm by
blocking the default ports used for SQL Server communication and establishing custom ports for this
communication instead. For services, lessen your attack surface area by disabling any service that is not
required by your database servers.
Best Practice: For services that you do need to run on your web, application, and database
servers in SharePoint 2013, apply the principle of least privilege to any service accounts.
Ports and protocols
There are several ports and protocols that are defined and required for SharePoint features and services to
operate successfully, and some of these should be modified for greater security.
Additional Reading: Ports and protocols are described in more detail later in this lesson.
Configuring Ports and Protocols

After securing the services on your web,
application and database servers, you need to
think about securing the ports that these servers
use to communicate with one another in a
Different SharePoint server roles use different
ports to communicate with each other.
Securing service application

communications
Communications between web servers and service
applications in a farm environment use the
following ports and protocol bindings by default:
HTTP: TCP 32843 (HTTP is the default binding)
HTTPS: TCP 32844 (SSL)
net.tcp: TCP 32845 (if a third-party developer has implemented this for its service application)
Securing web server communications

The following are the default ports used by SharePoint web servers in a farm:
HTTP: TCP 80
HTTPS: TCP 443 (SSL)
Securing database server communications

The following are the default ports used for SQL Server communications:
TCP 1433 (default)
UDP 1434 (used to query the server for list of named instances)
It is a best practice to block the TCP 1433 port on the SQL Server computer and configure a SQL Server
client alias to connect to the named instance instead.
Additional Reading: For more information about blocking the default port and creating
aliases, see Configuring SharePoint and SQL Server to Communicate Over Non-Standard Ports
later in this lesson.
Securing search server communications

The following are the default ports used by the SharePoint Search indexing components within a farm:
TCP: 16500-16519 inclusive
Securing Active Directory communications
The following are the default ports used to synchronize user profiles between SharePoint 2013 and Active
Directory Domain Services (AD DS) on the server that runs the Forefront Identity Management (FIM)
agent:
TCP and UDP: 389 (LDAP service)
TCP and UDP: 88 (Kerberos)
TCP and UDP: 53 (DNS)
UDP 464: (Kerberos Change Password)
TCP 5725: (FIM)
Securing external server communications
There are some SharePoint 2013 features that can be configured to access data on servers that are
external to the farm. In these scenarios, you need to ensure that the communication channels are open
between the local server and the remote server. Typically, the ports and protocols used will depend on the
external resource you are trying to access.
Additional Reading: For more information about hardening your servers in SharePoint
2013, see Plan security hardening for SharePoint 2013 at
Office Web Apps and Workflow Manager port considerations
You should not block the following ports on either the server that runs Office Web Apps Server, as Office
Web Apps Server periodically removes web applications on these ports:
Port 443 for HTTPS traffic.
Port 80 for HTTP traffic.
Port 809 for private traffic between the servers that run Office Web Apps Server (in a multi-server
farm).
10-7
You should also review the IIS Manager to view the ports used by Workflow Manager to ensure that these
are also available.
Configuring ports
There are several tools and technologies that you can use to configure ports and protocols for
SharePoint 2013. However, if you are using Windows Firewall with Advanced Security, when you install
SharePoint 2013, predefined inbound and outbound rules are automatically created to configure and
open the appropriate ports on the firewall for the installed services and applications.
Note: Important: Because the rules are predefined when using Windows Firewall with
Advanced Security, most of their properties, including port and protocol settings, cannot be
modified. However, you can use the Windows Firewall with Advanced Security console to
configure and change the ports and protocols of manually defined firewall rules.
Note: You can also use the Get-SPServiceHostConfig and Set-SPServiceHostConfig
Windows PowerShell cmdlets to view and configure ports and protocols. For more information,
see Get-SPServiceHostConfig at http://go.microsoft.com/fwlink/?Linkid=299761 and SetSPServiceHostConfig at http://go.microsoft.com/fwlink/?Linkid=299762
Configuring SharePoint and SQL Server to Communicate over NonStandard Ports

Although SQL Server uses a standard port to
communicate with other servers in a SharePoint
2013 farm, it is a best security practice to block the
standard port assigned to the default instance. To
protect against malicious users who will be aware
of the default port used, you should instead
reassign the default instance to a non-standard
port. A good example of this was the Slammer
worm virus, which targeted buffer overrun and
denial-of-service attacks on the SQL Server
Resolution Service, which is well-known to run on
UDP port 1434.
Whereas the default instance is assigned a static, well-known port number by default, named instances
are assigned random port numbers.
Best Practice: It is a recommended best practice for SharePoint farms to assign static port
numbers to named instances of SQL Server and block UDP port 1434, and to reassign the default
port used by the default instance and also block TCP port 1433.
Configuring a SQL Server instance to listen on a non-standard port

You configure a SQL Server instance to listen on a non-standard port by using the SQL Server
Configuration Manager console on the computer running SQL Server.
Perform the following steps to configure the SQL Server default instance to listen on a non-default port:
1.
Open SQL Server Configuration Manager.
2.
Expand SQL Server Network Configuration.
3.
Select the default instance, Protocols for MSSQLSERVER.
4.
Open the properties for the TCP/IP protocol.
5.
On the IP Addresses tab:
6.
a.
For each IP address except IPAll, clear all values for both TCP Dynamic Ports and TCP Port.
b.
For IPAll, clear the value for TCP Dynamic Ports, and for TCP Port, set another port number
value, for example 40000, that you want the default instance of SQL Server to listen on.
Restart the SQL Server service.
Blocking the standard SQL Server ports
If you are using Windows Firewall with Advanced Security at the time you install SharePoint 2013,
predefined inbound and outbound rules are automatically created to configure and open the appropriate
ports on the firewall for the installed services and applications. This is done to help secure the incoming
and outgoing network traffic. Because these rules are predefined and unsolicited traffic is blocked by
default, you do not need to explicitly block the standard SQL Server listening ports.
Configuring SQL Server client aliases
If you have blocked UDP port 1434 or TCP port 1433 as discussed earlier, you need to create an alias for
SQL Server clients so that they can successfully connect to the SQL Server. In a server farm, all web servers
and application servers are SQL Server client computers. When you create the alias, you specify the port
that the SQL Server instance in listening on.
You need to first install some SQL Server client components on the client computers so that they can
connect to the SQL Server instance.
To install the SQL Server client components:
1.
On each client computer, run Setup for SQL Server and select only the following client components
to install:
a.
Connectivity Components
b.
Management Tools (includes SQL Server Configuration Manager)
You configure client aliases by using the SQL Server Configuration Manager console on the client
computers.
Perform the following steps to configure a SQL Server client alias:
1.
On each client computer, open SQL Server Configuration Manager.
2.
Select SQL Native Client Configuration.
3.
In the Items window, right-click Aliases, and then click New Alias.
4.
Enter a name for the alias, and enter the port number for the database instance.
5.
Ensure that the protocol is set to TCP/IP.
6.
In the Server field, enter the name of the computer that is running SQL Server.
Additional Reading: For more information about configuring SharePoint 2013 and SQL
Server to communicate using non-standard ports, see Configure SQL Server security for
SharePoint 2013 environments at http://go.microsoft.com/fwlink/?Linkid=299763
Configuring Antivirus Settings

After you install a compatible antivirus scanner in
your farm, you can configure several antivirus
settings for SharePoint 2013 at the web
application level. These settings will not take effect
unless you install an antivirus scanner. There are
several antivirus products available that are
designed to integrate into the SharePoint
infrastructure.
Perform the following steps to configure Antivirus
settings for SharePoint 2013:
1.
In Central Administration, click Security.
2.
On the Security page, under General Security, click Manage antivirus settings.
3.
On the Antivirus page, you can configure the following settings:
10-9
Antivirus Settings. In this section, you can specify whether to scan the documents uploaded to or
downloaded from your document libraries and lists. You can also specify whether to attempt to
clean infected documents, and whether users can download infected documents.
Antivirus Time Out. This setting enables you to specify how long the virus scanner should run
before timing out. You can use this setting to reduce the load on the server by increasing the
value in the time out duration box. This will help improve server response times if they are
affected by antivirus scanning.
Antivirus Threads. This setting enables you to specify the number of execution threads that the
virus scanner can use on the server. You can decrease the number of threads to help improve
server response times if they are affected by antivirus scanning.

Scenario
10-10
server. Your team has installed SQL Server 2012 and SharePoint Server 2013. You have been assigned to
take various steps to improve the security of the server farm. As part of this process, you must configure
SharePoint and SQL Server to communicate on non-standard ports. You must also enable and configure
firewalls on both the database server and the SharePoint server.
Objectives
Configure SharePoint and SQL Server to communicate on non-standard ports.
Configure firewalls on database servers and SharePoint servers.

Virtual machines: 20331B-NYC-DC-10, 20331B-NYC-DB-10, 20331B-NYC-SP-10
Passw0rd: Pa$$w0rd
Exercise 1: Configuring SharePoint and SQL Server to Communicate Over

Non-Standard Ports
Scenario
In this exercise, you will configure SharePoint and SQL Server to communicate over non-standard ports.
First, you will configure SQL Server to listen on TCP port 55555 instead of the standard TCP port 1433.
Next, you will update the SQL Server alias on the SharePoint server so that SharePoint uses TCP port
55555 to communicate with the SQL Server instance on the database server.
1. Configure SQL Server to Use a Non-Standard TCP Port
2. Configure SharePoint to Communicate with SQL Server on a Specific Port
Task 1: Configure SQL Server to Use a Non-Standard TCP Port
Log on to the 20331B-NYC-DB-10 virtual machine as Contoso\Administrator with the password

Pa$$w0rd.
In SQL Server Configuration Manager, configure TCP/IP properties so that network communication
occurs over TCP port 55555.
Restart the MSSQLServer service, and then close SQL Server Configuration Manager.
Task 2: Configure SharePoint to Communicate with SQL Server on a Specific Port

Pa$$w0rd.
Open Internet Explorer, and then browse to sharepoint.contoso.com.
If you are prompted for credentials, log on as Contoso\Administrator with the password Pa$$w0rd.
Verify that the page displays an error message.
Note: This is because SharePoint is currently unable to communicate with the SQL Server
instance on the database server.
Close Internet Explorer.
Open the cliconfg utility.
Edit the ContosoDB alias to point to TCP port 55555 on the SQL Server instance.
Verify that the page loads successfully.
Results: After completing this exercise, you should have configured SharePoint and SQL Server to
communicate over a non-standard TCP port.
Exercise 2: Configuring Firewalls for SharePoint Server Farms

Scenario
In this exercise, you will configure Windows Firewall on the database server and the SharePoint server.
First, you will enable the firewall on the database server. Next, you will add an inbound rule to the firewall
that allows TCP traffic on the non-standard port you configured in the previous exercise. Finally, you will
enable the firewall on the SharePoint server and verify the settings.
1. Enable the firewall on the database server
2. Configure firewall exceptions on the database server
3. Enable the firewall on the SharePoint server
Task 1: Enable the firewall on the database server
In the Windows Firewall settings, turn on the firewall for the Domain profile.
Verify that the page displays HTTP 500 Internal Server Error.
Note: This is because the firewall on the database server is currently preventing SharePoint
from communicating with the database server.
Task 2: Configure firewall exceptions on the database server
In the Windows Firewall settings, create a new inbound rule with the following properties:
o
Allow TCP traffic over port 55555.
Apply the rule to the Domain profile but not the Private or Public profiles.
Name the rule SQL Server inbound TCP traffic from SharePoint.
10-12
Task 3: Enable the firewall on the SharePoint server
In the Windows Firewall settings, turn on the firewall for the Domain profile.
Review the existing inbound rules for the firewall, and notice that they include various rules to allow
communication between servers in the SharePoint farm:
o
The SharePoint sharepoint.contoso.com rule allows the SharePoint web application to

receive TCP traffic over port 80.
The SharePoint Central Administration v4 rule allows the Central Administration web
application to receive TCP traffic over port 50000.
The SharePoint Search rule allows various components of the search service to receive TCP
traffic over ports 16,500-16,519.
The SharePoint Web Services rule allows various Windows Communication Foundation (WCF)
based SharePoint web services to listen on TCP ports 32,843-32,845.
The SPUserCodeV4 rule enables the user code service for sandboxed solutions to listen on TCP
port 32,846.
Note: You do not need to configure an inbound firewall exception for SQL Server traffic on
port 55555 on the SharePoint server, because database communication takes place on the
outbound port 55555.
Results: After completing this exercise, you should have configured firewalls on a database server and a
SharePoint server.
Lesson 2
Configuring Farm-Level Security
10-13
In this lesson, you will learn how to configure farm-level security. Specifically, you will learn about
applying the principle of least privilege and delegated administration in your SharePoint 2013 farm, and
configuring blocked file types, Web Part security, Information Rights Management, and auditing.
Lesson Objectives
Apply the least privilege principle to SharePoint 2013.
Understand the delegated administration model.
Configure blocked file types in SharePoint 2013.
Configure Web Part security in SharePoint 2013.
Configure Information Rights Management in SharePoint 2013.
Configure activity and security auditing in SharePoint 2013.
Applying Least Privilege Principles

To design effective security for your SharePoint
2013 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, while still preventing inappropriate access.
The principle of least privilege is the cornerstone

of an effective security plan. This principle states
that you should grant users and service accounts
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 2013.
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 2013, you must apply this
principle to standard user accounts, groups, service accounts, and administrator accounts.
10-14
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 2013 infrastructure.
The following list describes some of the key areas that you should consider:
Installation privileges. SharePoint 2013 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 it
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.
In some cases, people use the SharePoint farm account to crawl content, 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.
Service accounts should not be members of the local Administrators group.
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 and you can run an application pool under a unique identity.
Application pool accounts should not be members of the local Administrators group.
Understanding the Delegated Administration Model

To maintain the highest levels of security and
manageability, you should use the delegated
administration model. In SharePoint 2013, you
need to think about delegating administration at
all levels in the platform hierarchy; farm-level, web
applicationlevel, site collectionlevel, and
sometimes even the site level. This means you
need to define staff members as farm
administrators, service application administrators,
and site collection administrators.
There are two key reasons why you should
delegate administration in SharePoint 2013:
10-15
Maintain least privilege principle. This approach ensures that there is no all-powerful administrator
of your SharePoint 2013 deployment and maintains security.
Improved manageability. Farm administrators are not the best candidates for someone to micromanage site collections. People need to have some responsibility and ownership over their own
content; otherwise, the content may not be maintained properly and it can expand out of control.
Levels of administration
There are several levels of administration in the SharePoint server and site hierarchy, and most of them
have corresponding administrative groups:
Server or farm level

o
Members of the Farm Administrators group have Full Control permissions for all servers in the
SharePoint farm. They can perform any administrative tasks in Central Administration for the
server or server farm. They can also delegate and assign administrators to manage other levels,
such as service applications. Members of this group do not have access to individual sites or their
content.
The local Administrators group on a SharePoint server is automatically added to the SharePoint
Farm Administrators group, so members of this group can also perform all farm administrator
actions. Administrators on the local server can perform additional tasks, such as installing new
products or applications, deploying Web Parts and new features, creating new web applications
and new websites. By default, members of this group on the local server do not have access to
site content.
Note: Farm Administrators and members of the local Administrators group can take
ownership of specific site collections if it becomes necessary, such as when another administrator
leaves the organization.
Service application level

o
Farm administrators can assign people to be service application administrators, which allows
them to configure settings for a specified service application. However, service application
administrators cannot create service applications, access any other service applications in the
farm, or perform any farm-level operations.
Farm administrators can also assign people to be feature administrators, who are associated with
specific features of a service application. Feature administrators are only able to manage a subset
10-16
of service application settings, but not the entire service application; for example, you might only
want them to be able to manage audiences of a User Profile service application.
Web application level

o
Web applications do not have a unique administrator group, but farm administrators have
control over the web applications within their scope. Members of the Farm Administrators group
can define policies to grant individual users permissions at the web application level if required.
Site collection level

o
Primary and secondary site collection administrators are defined when a site collection is created.
Site collection administrators have the Full Control permission level on all websites and site
content in their site collection. They can audit all site content and receive administrative
notifications from SharePoint.
Site owners have the Full Control permission level on that specific site. They can perform
administrative tasks on the site, and on any lists or libraries contained in that site. They receive
email notifications for events, such as the pending automatic deletion of inactive sites and
requests for site access.
Additional Reading: For more information about the levels at which you can delegate
administration of a SharePoint 2013 farm, see Choose administrators and owners for the
administration hierarchy in SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299764
Delegating service applicationlevel administration

As discussed earlier, you can delegate administration of a service application to a service application
administrator.
To delegate administration of a User Profile service application in Central Administration:
1.
In Central Administration, under Application Management, open Manage service applications.
2.
Select User Profile Service Application.
3.
On the Service Applications tab, in the Operations section, click Administrators.
4.
Add the user or group account you want to delegate administration to.
5.
Grant the user or group the Full Control permission level.
Additional Reading: For more information about delegating administration of the User
Profile service application, see Delegate administration of User Profile service applications in
SharePoint Server 2013 at http://go.microsoft.com/fwlink/?Linkid=299765
Delegating service application featurelevel administration
As discussed earlier, you can also delegate even further down the hierarchy and delegate certain features
of a service application to a feature-level administrator.
Perform the following steps to delegate administration of User Profile service application features in
Central Administration:
1.
In Central Administration, under Application Management, open Manage service applications.
2.
Select User Profile Service Application.
3.
On the Service Applications tab, in the Operations section, click Administrators.
4.
Add the user or group account you want to delegate administration to.
5.
Grant the user or group one, or more, of the following permission levels:
o
Manage Profiles
Manage Audiences
Manage Permissions
Retrieve People Data for Search Crawlers
Manage Social Data
Additional Reading: For more information about delegating administration of user profile
service application features, see Delegate administration of User Profile service application features
in SharePoint Server 2013 at http://go.microsoft.com/fwlink/?Linkid=299766
Configuring Blocked File Types

Because some executable files have the potential
to contain malicious code and could be run on
your servers, it is important to have a way of
controlling which files can be run or accessed on
your SharePoint servers.
You can prevent specific types of files from being
downloaded from, or uploaded to, a web
application in SharePoint 2013 by using the
Blocked File Types feature. Each web application
maintains its own list of these blocked file types.
SharePoint 2013 already has a large list of file
extensions that will be blocked by default, but you
can add additional file extensions as the need arises.
Additional Reading: For more information about the default blocked file types, see
Manage blocked file types in SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299767
Adding or removing blocked file types
10-17
When you want to prevent specific file types from being saved or retrieved from a web application on
your SharePoint 2013 server, you add them to a list on the Blocked File Type page. When you no longer
want to block them, you remove them from the list.
Perform the following steps to add or remove blocked file types by using Central Administration:
1.
In Central Administration, open Security.
2.
On the Security page, in the General Security section, click Define blocked file types.
3.
On the Blocked File Types page, select the relevant web application.
4.
Perform one of the following steps to block or unblock a file type:

o
To block a file type, scroll down to the end of the current list, and type the file name extension of
any new file types you want to block on a separate line, and then click OK. The next time that
you open the list, the file name extension you added will be correctly sorted in alphabetical
order.
o
To unblock a file type, delete the file name extension from the list, and then click OK.
When you make a change to the blocked file types list, the change automatically affects any new files
being added and files already on the website.
10-18
When a user tries to upload a blocked file, the SharePoint site displays an error message informing the
user that the file type is not permitted. If a user tries to access a file after the file type has been blocked,
the site displays an error message informing the user that the file type has been blocked.
Configuring Web Part Security

Web Parts are modular reusable components that
can be used on a SharePoint site to provide
extended functionality, such as document storage,
custom forms, lists, charting tools, and custom
search tools.
Web Parts are the fundamental building blocks for
every SharePoint site, and SharePoint 2013 comes
with many Web Parts supplied out-of-the-box.
Developers can also create their own custom Web
Parts.
These Web Parts can change the look and feel,
and even the functionality, of a website, so
securing them is a critical part of your farm security measures.
There are a few settings in SharePoint 2013 that enable you to control the security of Web Parts.
Managing Web Part security

You can configure security for Web Parts at the web application level or at the site collection level in
Central Administration.
Perform the following steps to manage Web Part security for a web application:
1.
2.
On the Security page, under General Security, click Manage web part security.
3.
On the Security for Web Part Pages page, select the web application you want to configure, and
then configure the following Web Part settings:
o
Web Part Connections. This setting specifies whether users are allowed to connect Web Parts by
passing data values from a source Web Part to a target Web Part. If you prevent users from
creating connections between Web Parts, you can help improve the security and performance of
the web application.
Online Web Part Gallery. This setting specifies whether users are allowed to access the Online
Web Part Gallery, which displays the available Web Parts that users can search for, preview, and
download to add to Web Part pages on their website. If you prevent users from accessing the
gallery to download Web Parts, you can help improve the security and performance of the web
application.
Scriptable Web Parts. This setting specifies whether contributors are allowed to add or edit
scriptable Web Parts.
10-19
If you want to manage Web Part security for a site collection to make them different from the default
settings, the exact same settings are also available at the site collection level.
Perform the following steps to access these settings:
1.
2.
On the list, click the site collection, and then on the ribbon, click Web Part Security.
Managing available Web Parts
You can view all the Web Parts available to your page owners and web designers and manage those Web
Parts in the Web Part Gallery.
Perform the following steps to view and manage the available Web Parts:
1.
On your site, click the Settings icon, and then click Site settings.
2.
On the Site Settings page, under Web Designer Galleries, click Web parts.
3.
In the Web Part Gallery, you can add, delete, preview, and modify the properties and permissions of
Web Parts.
Configuring Information Rights Management

Permissions and permission levels provide
administrators with a secure and flexible system of
authorization on the server. However, they do not
restrict the actions a user can take on a document
after it is downloaded to the client computer or
another location. For example, by granting Read
Items permission only, you can ensure that users
cannot make changes to the copy of a document
on the server. However, users could download that
document and make changes to their local copy.
IRM overview
Information Rights Management (IRM) is a

Microsoft persistent file-level technology that uses authorization and permissions to help you stop
sensitive information from being printed, forwarded, or copied by unauthorized users. After actions for a
document are restricted by IRM, the restrictions travel with the document as part of its contents.
Information Rights Management (IRM) can prevent such actions regardless of the location where a
document is stored. When you enable and configure IRM on SharePoint lists and document libraries,
SharePoint encrypts each document and adds an IRM license to it before it serves the document to a user.
This license lists the permitted actions on the document. So, by using IRM, you control which actions users
can take on documents when they open them from libraries in SharePoint 2013.
SharePoint permissions and IRM permissions
10-20
The IRM permissions that are included in the license map to the SharePoint permissions on the document
in the library. In the following table, you can see how SharePoint assigns these permissions.
SharePoint Permissions
IRM Permissions
Manage Permissions
Manage Web
Full control of the documents, as defined by the

client application. This generally permits the user
to read, edit, copy, save, and modify permissions
of the document.
Edit List Items

Manage List
Add and Customize Pages
Edit, copy, and save permissions. The user can

print the document only if the document library
IRM settings are configured to allow document
printing.
View List Item
Read permissions. The user can read the

document but not copy or edit its content. The
user can print the document only if the
document library IRM settings are configured to
allow document printing.
All other SharePoint permissions, such as

Edit User Info
Not applicable; no corresponding IRM

permissions.
Active Directory Rights Management Services
Before you can use IRM in SharePoint lists and libraries, you must set up the Active Directory Rights
Management Services in your organization. To do this, install the Active Directory Rights Management
Services (AD RMS) server role in Server Manager. You can configure a single AD RMS server to handle all
requests. However, it is recommended that you install several servers in a load-balanced configuration to
enable greater scalability and stability.
Configuring IRM in SharePoint 2013

After you install the AD RMS server role in your farm, you need to specify the location of an AD RMS
server in SharePoint 2013 in order to associate it with your farm.
Perform the following steps to associate an AD RMS server with your farm:
1.
2.
On the Security page, under Information Policy, click Configure information rights
management.
3.
On the Information Rights Management page, under Specify the location of Windows Rights
Management Service (RMS), click one of the following options:
o
Do not use IRM on this server
Use the default RMS server specified in Active Directory
Use this RMS server, and then type the name of an RMS server.
4.
Optionally, select the check box to allow tenants to configure tenant-level IRM settings.
5.
Click OK.
After an AD RMS server is associated with your farm, you can enable and configure IRM for your
SharePoint 2013 lists and libraries.
Perform the following steps to configure IRM for a SharePoint 2013 library:
10-21
1.
In the browser, open the library you want to secure.
2.
On the ribbon, click the LIBRARY tab.
3.
In the Settings group, click Library Settings.
4.
Under Permissions and Management, click Information Rights Management.
5.
On the Information Rights Management Settings page, select the Restrict permissions on this
library on download check box to apply restricted permission to documents that are downloaded
from this library.
6.
Create a permission policy title and description.
7.
Optionally, click SHOW OPTIONS to enable more granular usage rights.
8.
Click OK.
In Office 2013, the IRM settings user interface for a document library has been improved to make it easier
to use. When you click the SHOW OPTIONS link, you can also do the following:
Set additional IRM library settings. This includes specifying whether documents that do not support
IRM protection can be uploaded to the library; this also includes the ability to prevent the opening of
documents in the browser for a library.
Configure document access rights. This includes rights to print, run scripts to enable screen readers, or
enable writing on a copy of the downloaded document.
Set group protection and credentials interval. This setting controls the caching policy of the license the
application that opens documents will use, and enables you to allow sharing of the downloaded
documents with users in a specified group.
Note: IRM has been enhanced in the new Office to allow better integration with PDF files.
PDF readers can now register a control that enables easy opening of PDF files, and PDF
documents can be protected with IRM.
Configuring Activity and Security Auditing

You configure auditing in SharePoint 2013 to help
you track and record the actions of users in your
farm. The main reasons for configuring auditing
are for regularity and legal compliance; to track
how sites, content types, lists, libraries, and list
items are used; and to log the activities of your
farms users.
By examining audit reports regularly, you can be
confident that permissions are appropriate, users
are viewing information appropriate to their roles,
and sensitive documents are not being seen by
unauthorized personnel. Therefore, auditing is a
key component of your security infrastructure.
Configuring SharePoint auditing

Perform the following steps in SharePoint 2013 to configure auditing at the site collection level:
1.
In a site collection top-level site, click the Settings icon, and then click Site settings.
2.
Under Site Collection Administration, click Site collection audit settings.
3.
On the Configure Audit Settings page, you can configure the following:
10-22
Audit Log Trimming. In this section, you can specify whether the sites audit log should be
automatically trimmed. When you specify a particular event to be audited in a site collection, it
will be audited for each item in the site collection and every time the event occurs, which could
mean that a very large number of events will be generated. This will create a large audit log
which in turn could take up large amounts of hard drive space and affect the servers
performance. In this section, you can also specify a library to store audit log reports in before
they get automatically trimmed.
Documents and Items. In this section, you configure the specific events you want to audit for
documents and items in the site collection. It is recommended that you only configure auditing
on the events required to meet your needs. The events that you select to audit are captured in
audit reports based on Microsoft Excel 2010 and are available from the View Auditing Reports
page.
Lists, Libraries, and Sites. In this section, you configure the specific events you want to audit for
lists, libraries, and sites in the site collection. As before, only configure auditing on events that
meet your actual organizational needs.
Note: It is recommended that you only select opening or downloading documents, viewing
items in lists, or viewing item properties for SharePoint Server 2013 sites where and when it is
absolutely necessary, because this is likely to generate a large number of events.
Note: Important: If you are using SharePoint Online for Microsoft Office 365 for
enterprises, auditing for opening or downloading documents, viewing items in lists, or viewing
item properties is not available because of storage and performance concerns.
Additional Reading: For more information about configuring auditing for a site collection,
see Configure audit settings for a site collection at http://go.microsoft.com/fwlink/?Linkid=299768
Viewing audit reports
After auditing is configured and running, you should examine audit logs regularly to track unauthorized
or inappropriate access and activities. You can use the audit log reports that are provided with SharePoint
2013 to view the information in the site collections audit logs. Only site collection administrators can view
audit reports.
Perform the following steps to view audit reports in SharePoint 2013:
1.
In a site collection top-level site, click the Settings icon, and then click Site settings.
2.
Under Site Collection Administration, click Audit log reports.
3.
On the View Auditing Reports page, select one of a variety of auditing reports:
o
Content Activity Reports
Information Management Policy Reports
Security and Site Settings Reports
Custom Reports
4.
Browse to the library where you want to save the report, and then save it.
5.
On the Operation Completed Successfully page, you can view the selected report.
Note: In order to view audit log reports by clicking click here to view this report, either
Excel Services or Office Web Apps must be installed. Alternatively, if you have enabled opening
documents in the browser for the library, you can go to the library where you saved the audit log
report, point to the audit log report, click the down arrow, and then click View in Browser.
Additional Reading: For more information about viewing auditing reports, see View audit
log reports at http://go.microsoft.com/fwlink/?Linkid=299769

Scenario
10-24
The IT team at Contoso has now completed the server hardening process for the new SharePoint 2013
deployment. Your next task is to configure various farm-level security settings. To reduce the number of
large files on the SharePoint intranet, you must prevent users from uploading images in bitmap (.bmp) or
device independent bitmap (.dib) formats. This will force users to upload images in formats with smaller
file sizes. To reduce security risks and prevent excessive resource consumption, you must configure Web
Part security settings to prevent users from making connections between Web Parts or accessing the
Online Web Part Gallery. Finally, to meet the requirements of the audit and compliance team, you must
configure site collections to audit certain events, such as file deletions and permission changes.
Objectives
Configure blocked file types.
Configure web part security settings.
Implement activity and security auditing.

Passw0rd: Pa$$w0rd
Exercise 1: Configuring Blocked File Types

Scenario
In this exercise, you will configure blocked file types to prevent users from uploading bitmap (.bmp) or
device independent bitmap (.dib) files. You will then verify that you are unable to upload a bitmap file,
and also that you are still able to upload images in alternative formats.
1. Block bitmap file types at the web application level
2. Verify file type blocking
Task 1: Block bitmap file types at the web application level
On to the 20331B-NYC-SP-10 virtual machine, using the Central Administration website, block the
bitmap (.bmp) and device independent bitmap (.dib) file types on the sharepoint.contoso.com web
application.
Task 2: Verify file type blocking
In Internet Explorer, browse to sharepoint.contoso.com.
Attempt to upload the ContosoHeader.bmp image from the E:\Mod10 folder to the Site Assets
library.
Verify that you receive an error message that states your file has been blocked by the administrator.
Attempt to upload the ContosoHeader.jpg image from the E:\Mod10 folder to the Site Assets
library.
Verify that the image is added successfully.
Results: After completing this exercise, you should have configured blocked file types to prevent users
from uploading .bmp or .dib files.
Exercise 2: Configuring Web Part Security

Scenario
In this exercise, you will configure a connection between two Web Parts. You will then configure Web Part
security settings to prevent users from connecting Web Parts or accessing the Online Web Part Gallery.
Finally, you will observe the effects of your changes on existing Web Part connections and verify that you
are no longer able to create new Web Part connections.
1. Create a Web Part Connection
2. Configure Web Part security settings
Task 1: Create a Web Part Connection
When the page loads, notice that the Documents Web Part displays three documents.
Edit the page, and then add a Current User Filter Web Part to the content area.
Configure the Current User Filter Web Part to send filter values to the Documents Web Part.
Configure the Web Part connection to apply the filter to the Created By field in the Documents Web
Part.
Save the page, and notice that the Documents Web Part no longer displays any documents. The
documents are being filtered out because you did not create them.
Task 2: Configure Web Part security settings
On the Central Administration website, browse to the configuration settings for the SharePoint
sharepoint.contoso.com80 web application.
Configure the Web Part security settings to:

o
Prevent users from creating connections between Web Parts.
Prevent users from accessing the Online Web Part Gallery.
In Internet Explorer, browse to sharepoint.contoso.com.
Verify that the Documents Web Part is no longer filtering the list of documents.
Open the settings for the Current User Filter Web Part, and notice that the Web Part no longer
allows you to configure connections.
Results: After completing this exercise, you should have configured Web Part security settings to prevent
users from connecting Web Parts or accessing the Online Web Part Gallery.
Exercise 3: Implementing Security Auditing

Scenario
10-26
In this exercise, you will configure activity and security auditing on a site collection. You will configure the
audit log to record data whenever one of the following events occurs:
A user moves or copies a file to another location on the site.
A user deletes or restores a file.
A user changes permission settings anywhere on the site.
You will then change the permission settings on a document library and delete a document to create
some audit data. Finally, you will view the audit reports and verify that your changes were recorded.
1. Configure site collection audit settings
2. Create some audit data
3. View the audit reports
Task 1: Configure site collection audit settings
Configure the site collection audit settings as follows:
Automatically trim the audit log.
Retain audit log data for 28 days.
Configure the audit log settings to record the following events:

o
Moving or copying items to another location in the site
Deleting or restoring items
Editing users and permissions
Task 2: Create some audit data
Configure the Documents document library to stop inheriting permissions from its parent.
Remove the Contoso Intranet Portal Visitors group from the document library permissions.
Delete the StatementOfWork.docx file from the document library.
Task 3: View the audit reports
Browse to the audit log reports options for the site collection.
Run the Deletion report in the Content Activity Reports category. Save the report to the
Documents library when prompted.
View the report, and verify that it records the document you deleted in the previous task.
Run the Security settings report in the Security and Site Settings Reports category. Save the
report to the Documents library when prompted.
View the report, and verify that it refers to the permissions changes you made in the previous task.
Results: After completing this exercise, you should have configured site collection audit settings.
In this module, you learned about how to secure and harden your SharePoint 2013 farm deployment, and
how to configure several security settings at the farm level.
Review Question(s)
Test Your Knowledge
Question
Which of the following ports does not need to be opened to communicate with Active
Directory in order to synchronize user profiles with Forefront Identity Manager?
Port 53
Port 80
Port 389
Port 464
Port 5725
Test Your Knowledge
Question
Which of the following objects can you not set auditing for in SharePoint 2013?
Documents
Libraries
Lists
Sites
Web applications

11-1
Module 11
Managing Taxonomy
Contents:
Module Overview
11-1
Lesson 1: Managing Content Types
11-2
11-7
Lesson 2: Understanding Term Stores and Term Sets
11-11
Lesson 3: Managing Term Stores and Term Sets
11-15
Lab B: Configuring and Using Managed Metadata Term Sets
11-20
11-24
Module Overview
In order to organize information and make that information easier to find and work with, you can label or
categorize information. With files and items in Microsoft SharePoint, you can apply metadata, which could
be a category, a classification, or a tag, in order to organize your content and make it easier to work with.
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 Server 2013 can further enhance the application of metadata by using content
types. Organizations can use content types to standardize specific types of files, documents, or list items
and include metadata requirements, document templates, retention settings, and workflow directly.
Objectives
Describe the function of content types and explain how to apply them to business requirements.
Describe the function of managed metadata in SharePoint 2013.
Configure the Managed Metadata Service and supporting components.
Lesson 1
Managing Content Types
11-2 Managing Taxonomy
Organizations can use content types to streamline working practices in SharePoint 2013. You can create
templates for specific types of files, documents, or items 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.
Lesson Objectives
Identify valid taxonomy structures.
Identify the purpose of custom columns and site columns.
Identify the purpose of content types.
Create and publish a content type hub.
Outline the process for creating a content type and publishing a content type with the Managed
Metadata Service application.
What Are Taxonomies?

Within SharePoint 2013, an organizational
taxonomy is a classification mechanism, often
hierarchical in nature, which users in 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.
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 solicit stakeholder inputsuch as getting input from user teams
to establish the classification and taxonomy requirements of different teams. Consider holding
stakeholder meetings to help identify these requirements.
11-3
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 2013, organizations also have the capability to create folksonomies using the Enterprise
Keywords feature. A folksonomy is a more flexible way of organizing or categorizing content that users
can extend without administrator intervention.
Custom Columns and Site Columns

In SharePoint 2013, you can create custom
columns to hold information such as metadata or
item data. When creating 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 2013 or Active Directory directory
service users.
An image.
A calculation that is based on other column values.
A choice from a Managed Metadata term set.
You can create columns in a specific list or library. However, 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 instead of 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 top-level site 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, avoid using the same column name twice to clearly
establish metadata and column associations.
What Are Content Types?

Content types are a powerful method for creating
content of a certain type and automatically
associating columns, metadata, document
templates, information management policies, and
workflows with that type of item.
For example, consider the scenario where an
organization performs many projects. Each project
requires a specific business case for that project.
The organization already has a Word 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.
If you use a content type in this way, you only need to create that content type once. Any site in the site
collection that adds that content type will include all of the inherent functionality of that content type,
including the template, metadata, policy, and workflow functionality.
By modeling the information they store around content types, organizations can standardize associated
requirements and reuse templates, policies, and workflows.
Note: You can apply content types to lists and 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
11-5
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 2013 implementation, you must involve the necessary stakeholders (end-user
teams or departments) when you create your planned content types.
Publishing Content Types Across Site Collections

As with previous versions of SharePoint, in
SharePoint 2013, the content types that you create
in one site collection are restricted to use within
that site collection. By 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 for syndication.
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.
Perform the following steps to publish content types:
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.
2.
In the properties of the Managed Metadata Service, enter the URL of the site collection that will be
the content type hub.
3.
Create the content types in the content type hub.
4.
Publish the content types at the content type hub. The published content types will become available
in the consuming site collections after the Content Type Hub and Content Type Subscriber timer jobs
run.
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 the content type. 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.

Scenario
The IT team at Contoso is looking for ways to make the information architecture of the new SharePoint
2013 deployment easier to manage. To help ensure that documents and metadata are managed
consistently across departments, you decide to create a central content type hub. All content types will be
created on the content type hub and then published to make them available on other site collections.
Your first task is to create some site columns and content types that you can use to test the content type
publishing process. Next, you will configure a Managed Metadata Service application instance to
propagate content types from the content type hub to every web application that consumes the service
application. Finally, you will publish your content types and verify that they are available for use on other
site collections.
Objectives
Create site columns and content types for publishing.
Publish content types across site collections.

Password: Pa$$w0rd
Exercise 1: Creating Content Types for Propagation

Scenario
In this exercise, you will create some content types that you can use to test the content type publishing
functionality. First, you will create several site columns. You will then create two new content types that
rely on the site columns you created.
1. Create the Invoice content type
2. Create the Contract content type
Task 1: Create the Invoice content type

Pa$$w0rd.
Open Internet Explorer and browse to sharepoint.contoso.com.
Create the following site columns in a new group named Contoso Columns.
Name
Supplier
Single line of text
Payment Due Date
Date and Time
Contoso Department
Single line of text
Payment Amount
Currency
Create a new site content type with the following properties.

Property
Type
Value
Name
Invoice
Parent Content Type
Document
Group
Contoso Content Types
Add the Contoso Department, Payment Amount, Payment Due Date, and Supplier columns to the
Invoice content type.
Task 2: Create the Contract content type
Create the following site columns in the Contoso Columns group.

Name
Client
Single line of text
Final Effective Date
Date and Time
Contract Owner
Person or Group
Create a new site content type with the following properties.

Property
Type
Value
Name
Contract
Parent Content Type
Document
Group
Contoso Content Types
Add the Client, Contract Owner, and Final Effective Date columns to the Contract content type.
Results: After completing this exercise, you should have created several site columns and two content
types.
Exercise 2: Publishing Content Types Across Site Collections

Scenario
In this exercise, you will publish your new content types to make them available in other site collections.
First, you will provision a new Managed Metadata Service application instance. You will then publish the
content types and verify that they are added to the content type gallery in another site collection.
If you have already provisioned a Managed Metadata Service application instance (to enable you to
complete the demonstrations), you should skip to the final task in this exercise (Publish the content types).
1. Create a service account to run the Managed Metadata Service
3. Start the Managed Metadata Web Service service
5. Publish the content types

password Pa$$w0rd.

Property
Value
Full name
SharePoint General MMS
UPN logon
[email protected]
CONTOSO\ContosoMMS
Password
Pa$$w0rd
Selected
Selected
Register the CONTOSO\ContosoMMS account you created in the previous tasks as a managed
account.
Start the Managed Metadata Web Service service.
Managing Taxonomy
Navigate to the Manage Service Applications page on the Central Administration website.
Create a new Managed Metadata Service with the following settings.

Property
Value
Name
Contoso Managed Metadata Service
Database name
ContosoMMS
ContosoMMSAppPool
CONTOSO\ContosoMMS
Content type hub
11-10
On the site collection at http://sharepoint.contoso.com, activate the Content Type Syndication

Hub site collection feature.
Task 5: Publish the content types
In Internet Explorer, browse to the site collection at http://sharepoint.contoso.com.
Publish the Invoice content type.
Publish the Contract content type.
Locate and run the Content Type Subscriber timer job.
Note: The Content Type Subscriber timer job retrieves published content types from the
content type hub and adds them to the content type gallery in sites that subscribe to the
Managed Metadata Service application instance. By default, this timer job runs on an hourly
basis. In this case, you are running it immediately so that you can verify that your content types
were published successfully.
In Internet Explorer, browse to the Project Prototype site collection at

http://sharepoint.contoso.com/projects/P1.
Verify that the Invoice and Contract content types were added to the content type gallery for the
Project Prototype site collection.
Results: After completing this exercise, you should have provisioned a Managed Metadata Service
application instance and published content types across site collection boundaries.
Lesson 2
Understanding Term Stores and Term Sets
11-11
For SharePoint 2013 to deliver improvements in organizing data, you must understand the purpose of
metadata and the taxonomies that standardize the management of metadata. You must also understand
how to use the Managed Metadata Service in SharePoint 2013 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 custom taxonomy that is applicable for only certain groups or users.
Lesson Objectives
Identify options for managed metadata.
Identify elements in the term store.
Identify the capabilities of the Managed Metadata Service.
Plan for managed metadata in a multiple-farm environment.
Overview of Managed Metadata

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
2013, 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 can help with filtering views and displaying
relevant information.
You can search for content via metadata or keywords. Metadata is indexed and searchable, and you
can use the search results page to filter search results by metadata values.
You can use metadata to provide a navigation structure for sites and simplify the displayed URL of
key pages.
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
Managing Taxonomy
11-12
categories or classifications for documents. Terms are often closed so that only specified users can update
the list, providing a controlled taxonomy.
You can also use terms as navigation items on the quick launch (current navigation) or top link (global
navigation) areas. This is referred to as managed navigation and typically involves the use of a product
catalog and search-driven Web Parts.
Note: You must distinguish between terms and keywords. Typically, administrators
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 files or documents, 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 you can publish the site collection as a content type hub so that the content types
can be used in many site collections.
Additional Reading: For more information about managed metadata in SharePoint 2013,
see Plan managed metadata in SharePoint Server 2013 at
Introducing Terms and Terms Sets

SharePoint 2013 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 a
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. In SharePoint 2013, term groups can be local or global.
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 they are listed as a contact for query or reference
purposes.
11-13
Deprecating a term takes that term out of service, but it does not remove it from any items where that
term is already applied.
SharePoint 2013 stores terms, term sets, and term groups in the term store. There is one term store for
each instance of the Managed Metadata Service.
What Is the Managed Metadata Service Application?

The Managed Metadata Service application
performs two primary functions:
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.
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.
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.
Consuming Managed Metadata Across Farms

To provide enterprise scalability in SharePoint
2013, 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 Managed
Metadata Service for the core intranet farm
includes term sets for company departments,
office locations, product listings, and customers. It
publishes several content types, such as policy
Managing Taxonomy
11-14
documents, manufacturing procedures, and project documents. The Managed Metadata Service for the
research and development farm 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.
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.
Lesson 3
Managing Term Stores and Term Sets
11-15
When working with the Managed Metadata Service, it is important to understand that in addition to the
different elements present in the term store, how elements such as term sets and terms can be used in
SharePoint 2013 to affect user-facing content. You can use terms and terms sets in ways that affect list
displays and search results, in addition to new options such as managed navigation and faceted
navigation. You should also consider any multilingual content requirements and how these affect your
term set requirements.
Lesson Objectives
Create and manage term groups and term sets.
Identify scenarios for managed navigation.
Outline the process for configuring managed navigation.
Configure faceted navigation.
Configure multilingual support for term sets.
Creating and Managing Term Groups and Term Sets

In order to create a term group, you must be a
member of the Term Store Administrators group.
The entries for the Term Store Administrators
group are held at the root node of the Term Store
Management Tool.
Managing term groups

You can create a new term group using the menu
at the root node of the Managed Metadata
Service application in the Term Store Management
Tool. After creating the term group, you can:
Specify a description for the term group.
Specify one or more group managers who can manage all the term sets that are contained in the
term group.
Add users to the contributor role.
Specify contributors who can edit terms and term sets in the term group (although contributors
cannot add other users to the role).
In order to plan the term groups you require, you should consider who will manage term sets. If a term
set requires that only a restricted number of people have manager or contributor permissions, you should
consider creating a term group for that term set.
Managing term sets
You can create or import term sets using the menu at the appropriate term group node. After creating a
term set, you can configure the following options:
Description. This setting enables you to describe the purpose of the term set.
Managing Taxonomy
11-16
Owner. This setting represents the owner of the term set and can be an Active Directory user or
security group. By default, this value is set to the user account which created the term set. This setting
does not control any permissions or access over the term set; permissions are controlled at the term
group level.
Contact. Entering a value for the contact enables the term set suggestion feature. Suggestions enable
SharePoint users to suggest new terms for the term set by using the graphical user interface in the
site that the user accesses.
Stakeholders. This setting is a simple list of any users or groups in the organization that should be
involved or notified if changes are being considered for the term set. This acts as a reference for term
store administrators or term group managers.
Submission Policy. This setting controls whether non-contributor users can add terms to the term set.
The default value is Closed, which means that only members of the contributors, group managers, or
term store administrators groups can update the term set.
Available for Tagging. This setting makes the term set available to use in site collections and sites
within web applications that consume this managed metadata service application. The default value is
Enabled.
Use this Term Set for Site Navigation. This setting enables the term set to be used for managed
navigation. Managed navigation can replace the traditional method of site collection navigation,
which uses site structure and site hierarchy to populate global and current navigation areas, with
navigation links based on a hierarchical term set. This feature is most commonly used in conjunction
with a product catalog. The default value is disabled.
Custom Sort Order. The custom sort tab enables you to specify the order in which the terms of the
term set are displayed in site and item dialog boxes, forms, and pages. The default value is to sort
alphabetically based on the installed language.
Custom Properties. You can use the CUSTOM PROPERTIES tab to add additional associated settings
and corresponding values as a pair to the term set. These additional properties could include
additional descriptive information or specific references that should always be associated with the
term set.
You can also import term sets from a .csv file. To view a sample .csv file in the correct format for
importing, use the View a sample import file link available from the root node of the managed
metadata service application.
Managing terms
After creating the term set, you can start adding or managing terms. Each term has the following settings:
Available for Tagging. This setting makes the term available to use. The default value is Enabled.
Description. This setting enables you to describe the purpose of the term.
Labels. Terms in a term set may have several labels. Typically, each label carries the same or similar
meaning, but each may be used for historic reasons. For example, in a term set of organizational
departments, some people may use Human Resources department and Personnel department to
mean the same thing. You could create one term whose default label is Human Resources with an
additional label of Personnel. Whichever label users decide to categorize information by no longer
matters because both have the same term applied.
Custom Properties. You can use the CUSTOM PROPERTIES tab to add additional associated settings
and corresponding values as a pair to the term. These additional properties could include additional
descriptive information or specific references that should always be associated with the term. For
example, in a term set of organizational departments, you could add a department code as a custom
property to each department term. Properties can be shared or local; shared properties are available
11-17
if you reuse the term in the term store. However, local properties are only available to the instance of
the term where the property was added. Properties can be displayed using certain types of Web Parts,
such as the Term Property Web Part.
In addition to creating and deleting terms, you can also perform the following actions:
Copy Term. This option creates a copy of the term in the current term set.
Reuse Terms. This option adds the reused term and child terms under the selected destination.
Reused terms stay linked to the source terms that are used, so that renaming the source or reused
term will affect every location where the term is used.
Pin Term with Children. Pinning is similar to reusing terms, except that a pinned term cannot be
updated or changed where it is pinned; only the source term can be updated. If the source term is
updated, all pinned versions of the term will also be updated.
Merge Terms. This option merges the selected term and any associated labels into the target term.
Content tagged with the merged term will not be updated to the new term; instead, it will be
returned in searches for either the original or target terms.
Deprecate Term. This option prevents the term from being used any further, but it does not affect
items where the term has already been applied. Deprecated terms can be enabled later if required.
Move Term. This option moves the term from the current term set location to a new location in the
same or a different term set.
What Is Managed Navigation in SharePoint 2013?

In SharePoint 2013, you can use a hierarchical
term set as the basis for site collection navigation.
This is referred to as managed navigation, which
offers navigation links for the top link bar and the
quick launch area that is not based on the site
collection and site structure as with traditional
SharePoint navigation links.
You can use managed navigation in the following
scenarios:
To provide navigation links and hierarchy to a

site collection that uses mostly webpages for
content and does not use site structure. In this
scenario, such as a public internet site or a traditional non-collaborative intranet directory, there
would be a top-level site with a pages library. All required pages would be created in the pages
library. In previous versions of SharePoint, no navigation links would be created automatically
because there is no change to the structure (no subsites would be created). With managed navigation
enabled, when a new page is created, a corresponding term is automatically added to the term set
being used for managed navigation. Restructuring the term set hierarchy creates the navigation link
hierarchy and gives users the impression of content areas or sections to help navigate the content.
To provide navigation links and hierarchy to a product catalog solution. In this scenario, a product
catalog exists in a site collection. A product catalog is a specialized list that uses the Product and
Product with Image content types. Like in the previous page library example, the product catalog is a
flat list with no navigation hierarchy; however, you can create a corresponding publishing site using
managed navigation, where the navigation links are driven by a corresponding managed metadata
value from the product catalog. For example, if the product catalog was computer equipment, the
Managing Taxonomy
11-18
managed metadata you could use for navigation could be equipment type, such as desktop, laptop,
or server. Each of these terms could have various model names as subterms, driving the second-level
navigation. In this scenario, terms used for navigation are not directly associated with individual
pages; instead, all navigation terms point to a page template. The page templates are configured with
search-driven Web Parts that take search criteria automatically from the term set used for navigation
to provide specific content at a specific URL. The default page templates are category.aspx,
subcategory.aspx, and item.aspx.
Managed navigation also provides friendly URLs, which refers to URLs that do not end with entries such as
/forms/allitems.aspx. Friendly URLs would appear to the user as
http://sharepoint.litwareinc.com/sites/computers/desktops and the specific target page URL is hidden
from the user. You can configure the friendly URL assigned to a term and the target page URL when using
managed navigation by changing the settings on the term-driven pages tab of the term setting in the
Term Store Management Tool.
Configuring Refinement and Faceted Navigation

You can also use managed metadata to make it
easier for users to narrow down large lists or
libraries of content. This narrowing down process
is called refining. When you use certain Web Parts,
you can specify that a term set acts as a refiner,
enabling the user to select different criteria to view
within the list. For example, if you have products
listed with different colors, you could use the color
attribute as a refiner, so that a user could easily
get to all the products that are a specific color,
such as black. Refinement uses the Refinement
Web Part to alter the content shown in searchdriven Web Parts, such as the Content Search Web Part.
You can also use managed metadata terms for faceted navigation, which enables you to add additional
refiners to specific terms or term sets. These additional refiners are then used in conjunction with searchdriven content and refinement Web Parts.
For example, consider a catalog of computer equipment that includes laptops and desktop computers.
You may have already configured a term set to represent the type of equipment, such as laptop or
desktop, but there may be additional criteria that you also want users to be able to use to refine the
catalog items. Weight might be an important consideration for a laptop, but it is unimportant to a
desktop computer; therefore, you can configure faceted navigation on the term set so that the weight
attribute can be used for refinement, but only for items at or below the laptop term in the term set. In this
way, the weight attribute is not available as a refiner for desktop computers or other types of equipment.
To configure faceted navigation, go to the Site Settings page of the site collection where you want to use
faceted navigation, click Term Store Management Tool, and when you select a term set or individual
term, you will be able to select the faceted navigation tab and configure custom refiners for the term set
or term. By default, all terms inherit custom refiners from the parent term set, so in order to specify
custom refiners for individual terms, you must click Stop inheriting on the faceted navigation tab.
In order to use columns or managed metadata as refiners or for faceted navigation, you must ensure that
the relevant columns are searchable properties and the crawled properties are configured as refiners. In
SharePoint 2013, this can be done at the site collection level or at the search service application level. A
crawl of the relevant content must have been completed before the columns are available as crawled
properties.
Note: Faceted navigation is configured on a per-site collection basis, and you must use the
link to the Term Store Management Tool on the Site Settings page. If you connect to the Term
Store Management Tool by using the Manage Service Applications page in Central
Administration, you will not see the configuration options for faceted navigation.
Additional Reading: For more information about configuring refiners using managed
metadata, see Configure refiners and faceted navigation in SharePoint Server 2013 at
11-19
You can also use managed metadata to control the way lists or libraries are displayed by using the
metadata navigation option at the list settings level. If managed metadata is used for populating one or
more list columns, the associated term set will be available for configuring metadata navigation in the list
settings. This is an easy way to give users additional options for navigating a large list or library.
Configuring Multilingual Term Sets

By using labels, SharePoint 2013 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. This also provides a more consistent
search experience across multilingual content.
To implement multilingual term sets, you must
perform the following actions:
1.
Install the SharePoint Server 2013 language

pack for each language that you require.
2.
Use the Term Store Management Tool to add each language to the list of working languages for the
term store.
3.
Select one language to be the default language for the term store.
In SharePoint 2013, you can provide the additional language labels in two ways:
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.
You can use the Machine Translation Service to provide translations and labels for all terms in a term
set. The Machine Translation Service requires that your SharePoint server can communicate with the
Internet.
SharePoint will display the term by using the default language and label, regardless of the language that
you use to enter the term.
Managing Taxonomy
Lab B: Configuring and Using Managed Metadata Term

Sets
Scenario
11-20
As the next step in controlling and managing information architecture, you want to introduce centrallymanaged term sets to standardize how metadata is captured and recorded. This will enable users to tag
and locate information based on a consistent set of terms. Your team must implement a central
SharePoint 2013 term store and configure the Managed Metadata Service application to propagate term
sets to site collections across the organization.
Objectives
Configure the Managed Metadata Service application.
Create and configure term stores and term sets.
Share term sets across site collections.

Password: Pa$$w0rd
Exercise 1: Configuring the Managed Metadata Service

Scenario
In this exercise, you will configure term store administrators for the Contoso Managed Metadata Service.
This enables other users to create and manage term set groups, term sets, and terms.
1. Assign term store administrators
Task 1: Assign term store administrators
Launch the SharePoint 2013 Central Administration website.
Add contoso\jim to the term store administrators for the Contoso Managed Metadata Service
application.
Results: After completing this exercise, you will be able to configure term store administrators.
Exercise 2: Creating Term Sets and Terms

Scenario
In this exercise, you will create several term sets and terms. First, you will create a new term set group
named Organization in which to store your term sets. You will then create term sets named Department
and Supplier and add several terms to each term set.
1. Create the Department term set
2. Create the Supplier term set
Task 1: Create the Department term set
In the Contoso Managed Metadata Service term store, create a new term set group named
Organization.
In the Organization group, create a new term set named Department.
Add the following terms to the Department term set:

o
Marketing
Finance
IT
Sales
Task 2: Create the Supplier term set
In the Organization group, create a new term set named Supplier.
Add the following terms to the Supplier term set:

o
Litware, Inc.
Proseware, Inc.
Northwind Traders
Trey Research
Wide World Importers
Results: After completing this exercise, you will be able to create term set groups, term sets, and terms.
Exercise 3: Consuming Term Sets

Scenario
In this exercise, you will test the term set publishing functionality in your SharePoint 2013 deployment.
First, you will replace the Contoso Department and Supplier site columns you created earlier with
managed metadata columns that use the Department and Supplier term sets, respectively. Next, you will
update the Invoice content type to include the new managed metadata columns, and you will republish
the term set. Finally, you will apply the content type to a document library on a separate site collection
and verify that both the content type and the managed metadata columns behave as expected.
1. Replace the Supplier site column with a managed metadata column
2. Replace the Contoso Department column with a managed metadata column
3. Edit and republish the Invoice content type
4. Verify that the republished content type and managed metadata columns behave as expected
Managing Taxonomy
Task 1: Replace the Supplier site column with a managed metadata column
Open Internet Explorer, and browse to http://sharepoint.contoso.com.
Create a new site column with the following properties.

Property
Value
Name
Supplier (MMS)
Type
Managed Metadata
Group
Contoso Columns
Term Set
Contoso Managed Metadata Service >

Organization > Supplier
11-22
Note: You cannot convert a text-based column into a managed metadata-based column. Instead,
you must create a new managed metadata-column to replace the text-based column.
Task 2: Replace the Contoso Department column with a managed metadata column
Create a new site column with the following properties.

Property
Value
Name
Contoso Department (MMS)
Type
Managed Metadata
Group
Contoso Columns
Term Set
Contoso Managed Metadata Service >

Organization > Department
Task 3: Edit and republish the Invoice content type
On the sharepoint.contoso.com site collection, browse to the settings for the Invoice content type.
Remove the Supplier and Contoso Department columns from the Invoice content type.
Add the Supplier (MMS) and Contoso Department (MMS) columns to the Invoice content type.
Republish the Invoice content type.
On the Central Administration website, locate and run the Content Type Subscriber timer job.
Task 4: Verify that the republished content type and managed metadata columns
behave as expected
In Internet Explorer, browse to http://sharepoint.contoso.com/projects/P1.
Edit the Documents document library setting to allow management of content types.
Add the Invoice content type to the document library.
From the E:\Mod11 folder, upload the Invoice.docx file, and then set the content type to Invoice.
Verify that you can choose terms from the Department and Supplier term sets to complete the
Contoso Department (MMS) and Supplier (MMS) fields.
Results: After completing this exercise, you will be able to use managed metadata term sets in site
columns and content types.
Managing Taxonomy
11-24
In this module, you learned how to create and configure content types and how content types can be
shared across multiple site collections. You also learned how to configure the Managed Metadata Service
to create and manage a taxonomy and to provide capabilities such as refinements and managed
navigation.
Review Question(s)
Question: Why is stakeholder input important to help establish the taxonomy?
Question: Can more than two farms share term sets or content types through publishing the
Managed Metadata Service?
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?

12-1
Module 12
Configuring User Profiles
Contents:
Module Overview
12-1
Lesson 1: Configuring the User Profile Service Application
12-2
12-9
Lesson 2: Managing User Profiles and Audiences
12-13
12-17
12-23
Module Overview
Social computing environments enable organizations to quickly identify colleagues, team members, and
others with similar roles or requirements in an organization. Social features in Microsoft SharePoint
Server 2013 enable users to quickly gain updates and insight into how other members of the organization
are working and what information or processes people are developing, along with the progress being
achieved.
The SharePoint 2013 social platform is based around the capabilities provided by the user profile service
application, supported by other services, such as the Managed Metadata Service and the Search service.
The User Profile Service provides configuration and control over importing profile data, creating My Sites,
managing audiences, and users can utilize these features.
Objectives
Plan for and configure user profile synchronization with Active Directory Domain Services.
Plan for and configure My Sites and audiences.
Lesson 1
Configuring the User Profile Service Application
12-2 Configuring User Profiles
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.
Lesson Objectives
Describe how the User Profile Service supports social computing.
Describe the purpose of user profiles.
Explain how to plan the synchronization of user profile information.
Describe the process for configuring Active Directory user profile import.
Describe the process for Active Directory user profile synchronization.
Explain how to configure user profile properties.
What Is the User Profile Service Application?

The User Profile Service is a service application in
Microsoft SharePoint Server 2013 that provides a
central location for configuring and managing the
key elements of personalization settings. The User
Profile Service holds the settings for 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.
Profile synchronization. You can synchronize

user profile information that the User Profile
Service stores with external directory services such as Active Directory Domain Services. 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 jobs or tasks. 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 websites. You must provision a My
Site Host before you can deploy the social features of SharePoint 2013.
My Site website. Each user in your organization who has a synchronized user profile can have a
personal site. Users can store documents, manage the content of their My Site website, and share
content with others. The My Site content storage is also referred to as SkyDrive@<companyname>.
Social tags and notes. Users can add social tags to documents, to other SharePoint items, and to other
objects, such as external webpages and blog posts. Users can also create notes on any SharePoint
12-3
page. Administrators can delete all tags for employees when they leave the company or remove a tag
that they do not want.
User personalization permissions. You can use permissions settings within the User Profile Service
application to control which users can edit profiles, use personal sites, and use tags and notes.
You cannot access the Manage Profile Service page until an instance of a User Profile Service application
exists and the associated services are started. You can use the SharePoint Central Administration website
in addition to Windows PowerShell to create and manage User Profile Service applications and other
service applications for non-hosted environments. You can also delegate management of a User Profile
Service application to someone who does not have permissions to manage other services or settings
contained in Central Administration.
Note: Organization profiles have been deprecated in SharePoint 2013. Although you can
still configure and use Organization profiles, they will not be supported in future versions of
SharePoint.
What Are SharePoint User Profiles?

SharePoint user profiles contain information about
one or more users stored as attributes or
properties. These properties might include
telephone numbers, department information,
location information, or skills. User profiles enable
users to share their key information with other
individuals in the organization.
SharePoint User Profile Service provides the
following benefits:
Profile data can be aggregated from multiple

sources.
Content can be indexed by SharePoint Search to allow for searching of individuals that match certain
criteria, such as skills, within your organization.
Profile information can be used to target information (in Web Parts and dashboards) to specific users.
Profiles include a description of memberships and distribution lists to which a user belongs.
Profiles provide a way to track a users people associations in the form of colleagues.
User profile storage and customization
User profile information is stored in a Microsoft SQL Server database separate from the Configuration and
Content databases. You can map user profiles and associated attributes to Active Directory Domain
Services (AD DS) users or other types of stores.
Note: AD DS attributes and user profile properties may not necessarily match, particularly
where users are provided the ability to control their own information. This can make the
synchronization and process a little complex. Knowing and understanding ADSI Edit is
recommended.
Planning User Profile Import

When planning to import user profile information
and create SharePoint user profiles, there are
several aspects that you should consider. It is
important that you consider the context of user
profile information and the planned purpose of
user profiles for the business.
User profiles
Locating people and expertise is the key to
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 can you synchronize from directory services or business systems?
Which synchronized profile properties will map to default properties?
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 website?
User profile import or synchronization

You must plan for the method that you will use to import external data into SharePoint user profile
properties. You can use the following two methods:
User profile import
This method enables you to import user information from Active Directory Domain Services (AD DS) into
users SharePoint profile properties. This method can only import from AD DS and cannot use any other
source for profile information. This method is quicker to set up than user profile synchronization and
usually quicker to execute, but it only allows import of profile information. You cannot export SharePoint
user profile information using this method.
Determining objects to import
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. User profile import enables you to ignore disabled user accounts and to use a
Lightweight Directory Access Protocol (LDAP) filter to include only specific user or group objects to import
based on user account or group attributes in AD DS.
User profile synchronization
This method is a little more complex and takes longer to set up than the user profile import method, but it
allows you to use external sources, such as IBM Tivoli Directory Server, Novell eDirectory, or Business Data
Connectivity (BDC), in addition to AD DS. User profile synchronization also allows you to export most user
profile properties into AD DS. However, a specific profile property can only be imported or exported;
SharePoint user profile synchronization does not provide a two-way synchronization for a single property.
Determining objects 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. You should also identify any profile information that you want to exclude
from synchronization before the initial synchronization takes place. User profile synchronization enables
you to create connection filters that enable you to exclude user or group objects from synchronizing
based on user account or group attributes in the source directory.
Note: As a best practice, you should have at least one instance of the Managed Metadata
Service running in your farm before creating importing or synchronizing user profiles from Active
Directory Domain Services. This is because in SharePoint 2013, some profile properties are
automatically configured to use term sets, and will populate the term set automatically from the
user profile data during synchronization.
Planning permissions
After you identify 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 2013 and the directory
service or business system to which you will connect. Regardless of whether you plan to use the import or
the synchronization method, it is required that the account you use for connecting to AD DS has the
Replicating Directory Changes permission set to allow on the domain object in Active Directory. It is
also recommended that the account you use for profile synchronization is configured with the
Replicating Directory Changes permission set to allow on the configuration object in Active Directory in
order to avoid issues caused by NetBIOS domain names not matching Active Directory Fully Qualified
Domain Names (FQDNs).
Mapping profile properties
After you identify the containers that you want to import and synchronize with SharePoint 2013, you must
map the profile properties in the directory service or business system to the profile properties in
SharePoint 2013. You should also consider any properties that map across multiple directory services or
business systems, because you must create these mappings manually.
Defining a synchronization schedule
SharePoint 2013 uses two different types of schedules: 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.
However, a full user profile import is usually significantly faster than a full synchronization. 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 planning user profile importing, see Plan
user profiles in SharePoint Server 2013 at http://go.microsoft.com/fwlink/?Linkid=299772
Creating a User Profile Service Application for Active Directory Import

The way in which you configure the User Profile
Service application and the related service
instances dictates whether import or
synchronization modes are available to you. You
can use the following procedure to create a User
Profile Service application and configure Active
Directory import:
1.
Create a service account to use for AD DS

profile import. This account must have the
Replicating Directory Changes permission
on any objects and containers that you need
to import from.
2.
For best practice, create a web application to use for hosting personal sites. Personal sites should have
a dedicated web application, because the Self-Service Site Creation feature must be enabled on this
web application for users to create their own My Sites. After creating the web application, create a
site collection at the root URL of the web application using the My Site Host template.
3.
Start an instance of the User Profile Service from the Manage services on server page.
4.
Create a new User Profile Service application. During creation of the service application, you will need
to specify the profile database, the synchronization database, the social tagging database, the
application pool to use, and the URL where personal sites should be created.
5.
Manage the User Profile Service application, and select Use SharePoint Active Directory Import on
the Configure Synchronization Settings page. Note that after selecting the Active Directory import
option, synchronization options, such as using BCS connections for synchronization, become
unavailable.
6.
Use the Configure Synchronization Connections page to create a new connection for your Active
Directory import. You must specify the domain name, and Active Directory containers to import, in
addition to a user account with Replicating Directory Changes permission on the objects to import.
You should use the service account you created previously for this purpose. This account should not
be a managed account in the SharePoint farm.
7.
Start full profile synchronization from the Start Profile Synchronization page.
8.
Additionally, you may want to set the import schedule. You can do this from the Configure
Synchronization Timer Job page. The default schedule is an incremental import every five minutes.
Using Windows PowerShell to create the User Profile Service application
If you are going to create the User Profile Service application by using Windows PowerShell, you should
be aware that you must run the New-SPProfileServiceApplication cmdlet as the farm account. However,
logging on interactively as the farm account is not recommended. You should treat the farm account as a
service account and avoid performing administrative tasks using this account unless absolutely necessary.
Unexpected consequences may occur as a result of using this account to perform administration tasks that
do not require this high level of privilege. You can overcome this issue by using the Start-Job cmdlet and
providing the farm account credentials. The following sample script uses this method:
Windows PowerShell script for creating the User Profile Service application
$sb = {
Add-PSSnapin Microsoft.SharePoint.PowerShell
$saAppPool = Get-SPServiceApplicationPool "SharePoint Web Services Default"
$upa = New-SPProfileServiceApplication -Name "User Profile Service Application" `
-ApplicationPool $saAppPool `
-ProfileDBName "UPA_Profile" `
-SocialDBName "UPA_Social" `
-ProfileSyncDBName "UPA_Sync" `
-ErrorAction SilentlyContinue -ErrorVariable er
}
$cred = Get-Credential "contoso\sp.farm"
$job = Start-Job -Credential $cred -ScriptBlock $sb | Wait-Job
New-SPProfileServiceApplicationProxy -Name "User Profile Service Application Proxy" `
-ServiceApplication $upa `
-DefaultProxyGroup
Configuring User Profile Properties in SharePoint

A profile property is the field that holds
information about a particular user in your
organization. An extensive set of fields is available
and included by default, such as skills, birthday,
manager, and responsibilities.
In many implementations, the default properties
may be enough, but there are likely scenarios and
situations that require the creation of custom
properties. Examples might include items that
describe a training path, certification, or product
specialty.
When creating custom properties for user profiles,
you can specify a data type to use for the field. Data types include:
Integers
Binary values
Yes/No values
Dates
Email addresses
Floating point numbers
HTML content
SharePoint users
Multi-value or single-value text
Time zone
Unique ID
URLs
You can also provide centrally defined values from the term sets in the Managed Metadata Service to
standardize on options and organizational policies.
12-7
Profile data is stored in a SharePoint profile database as a replica of the source data. Based on the security
settings of the profile properties, users may actually be able to edit these properties by using their My Site
or any custom profile editing page. Developers can also write tools to update profile properties rather
than using the importing mechanisms in SharePoint.
Policy setting
Each profile property has a policy that is specified by an administrator. The policy controls whether the
property has to have a value present. The valid settings for the property policy are:
Required. The property must have a value.
Optional. The property does not need to have a value.
Disabled. The property will not be used or displayed.
Privacy setting
Each profile property also has a privacy setting. The privacy setting enables administrators to specify who
will be able to view this particular property when viewing the profile of a user. The default privacy setting
can be Everyone or Only Me. Administrators can also allow users to override the default value, so that
the user controls who can see that property.
User Profiles in SharePoint Online

If you have an implementation of Microsoft Office
365 or SharePoint Online, you may use My Sites
within the SharePoint Online environment. My
Sites in SharePoint Online offer similar levels of
functionality to My Sites in on-premises
deployments, including personal storage areas,
tagging, note boards, newsfeeds, and the
organization browser.
If you do not have an on-premises AD DS instance,

you can manually input user profile information
into the Office 365 directory using the Office 365
Admin Center. However, if you have an onpremises AD DS deployment, you can configure Active Directory user information to populate SharePoint
Online user profile properties.
In order to synchronize on-premises AD DS user information to SharePoint Online user profiles, you must
utilize the Office 365 Directory Synchronization Tool (DirSync). This tool should be installed on a
dedicated computer in your organization, where it copies objects from your on-premises AD DS
environment to the Office 365 directory. After the objects are copied to the Office 365 directory service,
SharePoint Online can bring that information into the SharePoint user profiles. Directory synchronization
is only one-wayfrom the on-premises AD DS environment into Office 365.
Note: After implementing DirSync, it is important to manage user accounts and other
directory objects by using on-premises management tools, such as Active Directory Users and
Computers.
Additional Reading: For more information about profile synchronization, see Manage user
profiles in SharePoint Online at http://go.microsoft.com/fwlink/?Linkid=299773
For more information about the Office 365 directory synchronization tool, see Active Directory
Synchronization in Office 365 at http://go.microsoft.com/fwlink/?Linkid=299774

Scenario
Contoso has never had a centralized employee directory despite the multiple requests by the Human
Resources department. Since implementing SharePoint 2013, the Human Resources department has again
requested the directory be implemented. Your team must implement the employee directory by using
SharePoint user profiles, with Active Directory as the primary data source.
Objectives
Configure the User Profile Service application.
Configure directory import and synchronization settings.

Password: Pa$$w0rd
Exercise 1: Creating a User Profile Service Application

Scenario
In this exercise, you will create an instance of the User Profile Service application. You will create service
accounts and grant the service account the permissions required to replicate the directory. You will then
start the required services. Finally, you will create an instance of the User Profile Service application.
1. Create a service account for the service application
2. Grant the SPFarmAccount the Replicating Directory Changes permission
4. Start the User Profile Service instance
5. Create a new User Profile Service application instance
Task 1: Create a service account for the service application
password Pa$$w0rd.

Property
Setting
Full name
Profile Service
UPN logon
[email protected]
contoso\ProfileService
Password
Pa$$w0rd
Selected
Selected
Task 2: Grant the SPFarmAccount the Replicating Directory Changes permission
View the properties for the contoso domain.

Grant the Replicating Directory Changes permission to the SPFarm user account.
Register the CONTOSO\ProfileService account you created in the previous tasks as a managed
account.
Task 4: Start the User Profile Service instance
Browse to the Services on Server page.
12-10
Start the User Profile Service instance.

Verify that the service starts successfully. You may need to refresh the page to update the status and
the service may take some time to start.
Task 5: Create a new User Profile Service application instance
Browse to the Manage Service Applications page.
Create a new instance of the User Profile Service Application service application with the following
properties.
Property
Setting
Name
Contoso UPSA
ContosoUPSAAppPool
Application pool service account
CONTOSO\ProfileService
Verify that the service application and a corresponding service application proxy are now included in
the list of service applications.
Results: After completing this exercise, you should have created a new instance of the User Profile Service
application.
Exercise 2: Configuring Directory Import

Scenario
In this exercise, you will configure the User Profile Service application for import-only synchronization.
You will then configure the connection to Active Directory and perform an initial synchronization. Finally,
you will test the profile import by viewing a user profile in SharePoint and verifying that the user account
has imported correctly.
1. Configure the User Profile Synchronization Service application instance for import-only synchronization
2. Configure a connection to Active Directory
3. Configure profile synchronization
4. Test profile synchronization
Task 1: Configure the User Profile Synchronization Service application instance for
import-only synchronization
Configure the Contoso UPSA service application to use SharePoint Active Directory Import.
Task 2: Configure a connection to Active Directory
Create a new synchronization connection with the following properties.

Property
Setting
Connection name
Contoso Domain
Type
Active Directory Import
Domain name
contoso.com
Account name
CONTOSO\SPFarm
Password
Pa$$w0rd
Containers to synchronize
All
Task 3: Configure profile synchronization
Browse to the application management page for the Contoso UPSA service application.
Enable the synchronization timer job. Accept the default schedule.

Browse to the application management page for the Contoso UPSA service application, and then
start a full profile synchronization. Wait for the synchronization to complete before continuing.
Task 4: Test profile synchronization
Browse to the Manage User Profiles page.
View the user profile for the CONTOSO\Jim user account.
Note: Some fields will display error messages. This is expected because you have not
configured all of the social features in SharePoint 2013 to support these fields, for example My
Sites.
12-12
Results: After completing this exercise, you should have configured and validated a user profile import
from Active Directory.
Lesson 2
Managing User Profiles and Audiences
12-13
After creating a User Profile Service application and importing user profile data, the next step is typically
to provision personal sites for users, called My Sites. In SharePoint 2013, My Sites form the backbone of
many social computing features, even if personal storage areas are not required.
Lesson Objectives
Configure My Site settings
Describe the process for configuring a My Site host
Configure social permissions
Configure audiences
Describe the management of My Sites and audiences in SharePoint Online
Configuring SharePoint for My Site Deployment

In order to deploy My Sites, you must specify a
location for My Site deployment. You can specify
the My Site location either when setting up the
User Profile Service application, or after the User
Profile Service application has been created.
As a best practice, the location you select for My

Site deployment should be a dedicated web
application. Although My Sites can exist on a web
application with other content, putting My Sites
on a dedicated web application will enable you a
greater degree of management and control over
My Sites, with less impact on other web
applications. This is because the web application to which you deploy My Sites requires the Self-Service
Site Creation feature enabled at the web application level. Also, using a dedicated web application ensures
that My Site content is not sharing a database with other content, which can help in disaster recovery
scenarios by keeping the database size smaller and more manageable.
In order to configure My Sites, you should perform the following tasks:
1.
Create a new web application for My Sites. If this web application requires a host header, you must
also add the relevant DNS entry.
2.
Enable Self-Service Site Creation for the web application.
3.
Create a site collection at the root of the web application (/) using the My Site Host template.
4.
In the User Profile Service application, on the Setup My Sites page, enter the URL of the site collection
with the My Site Host template, and choose a managed path to use for the web application.
You can also specify that the My Site Host URL should be published to Active Directory in order to assist
integration with applications such as Microsoft Outlook in Microsoft Exchange 2013.
If you have multiple farms, each with a User Profile Service application, such as in a scenario with multiple
offices, geographically dispersed, you must plan for My Site deployment to ensure that multiple My Sites,
12-14
one for each farm, are not created. You can prevent this behavior by configuring trusted host locations
from the User Profile Service application of each farm, using audiences to specify users who have a My
Site hosted by a different User Profile Service application.
Permissions for SharePoint Social Features

In the User Profile Service application, you can
control which users are able to use social features
by using permissions. The following permissions
exist within the user profile service application:
Create personal site. This permission enables

users to create a personal site to store
documents, newsfeed, and followed content.
Follow people and edit profile. This permission

enables users to follow other users from a
personal site and enables users to update
SharePoint user profile information.
Use tags and notes. This permission enables users to use the tags and notes feature to tag documents
or pages, or to add notes to a page. This functionality is primarily intended to support backward
compatibility with SharePoint 2010.
Using these permissions, you can control who has access to personal sites and social capabilities in a
variety of scenarios. For example, you can prevent all users from having access to certain features by
removing the authenticated users group from the relevant permission. Using permissions also provides
the ability to enforce a controlled rollout of social features across a large number of users, by removing
the authenticated users group, and gradually adding more groups across the organization to enable social
features for users department by department, or location by location.
Note: The tags and notes button on the ribbon will not be disabled if a user does not have
the Use tags and notes permission. This is because the tags and notes button is added through
a farm-level feature. If nobody will be using tags and notes, it is recommended that you disable
the farm-level feature to remove the entry from the ribbon.
Configuring Audiences
Audiences give site collection administrators, site
owners, and content editors the ability to target
content to specific collections of users. When an
audience is used to target content, such as
navigation links or Web Parts, the targeted
content only appears to users that are part of the
corresponding audience. This enables you to have
fewer pages of content that have less clutter on
the page or offer page content that is much more
relevant to a users requirements and job tasks.
Audiences are defined within the User Profile
Service application by matching users to a rule.
You can create rules that are based on Active Directory groups, the Reports Under field in Active
Directory, or any SharePoint user profile property.
Perform the following steps to create an audience:
12-15
1.
Go to the Manage Profile Service page for your User Profile Service application, and then click
Manage Audiences.
2.
On the View Audiences page, click New Audience.
3.
On the Create Audience page, enter the name of the audience, specify the owner of the audience,
and choose the option for multiple rule evaluation. You can choose Satisfy all of the rules, which is
equivalent to logical AND for multiple rules, or you can choose Satisfy any of the rules, which is
equivalent to logical OR for multiple rules.
4.
On the Add Audience Rule page, you can specify how you want SharePoint to evaluate which users
are members of the audience. Choosing the User operand enables you to select an Active Directory
group or the manager field from Active Directory as the criteria for matching users to your rule.
Choosing Property enables you to select a SharePoint user profile property to match the rule against.
Compile audiences
After you create an audience and specify one or more rules for the audience, an audience must be
compiled before the audience is available for use to target content in a site. You can compile audiences
on a schedule or manually. By default, audience compilation is scheduled to occur weekly, although you
also have the option to schedule audience compilation as a daily or monthly task as well. You should set
the schedule to align with the frequency of changes that can occur to Active Directory or SharePoint user
profile data, in order to reflect changes as quickly as possible, making audience membership dynamic. In
addition, you can also manually compile audiences.
Manual compilation is useful when you do not want to wait for the next scheduled compilation, such as
after creating a new audience for the first time or when significant changes have been made to user
profile information. You can compile all audiences together from the Manage Profile Service page, or
compile audiences individually from the View Audiences page.
Note: Audiences are not a security feature. Although audience membership results in
certain items, such as navigation links and Web Parts on a page being hidden from some users,
the content in those links and Web Parts may still be accessible to users who are not part of the
targeted audience if the user knows the URL or if a link is provided elsewhere.
My Sites and Audiences in SharePoint Online

My Sites in SharePoint Online behaves in a similar
way to on-premises deployments, with features
such as personal storage and social tagging. In
SharePoint Online, you can configure the
following My Site options:
Search center. You can specify the SharePoint

Search Center that will be used when a user
searches from the My Site profile page.
Search scope. You can define the default

search scope used for finding people and
documents.
12-16
Language. You can enable users to choose the language of their My Site.
Read permission level. You can specify which users or groups have read permission to personal sites
by default. The default setting is authenticated users.
Security trimming. You can set the security trimming behavior, so that all links are checked for
permissions, which is the default, or you can specify that security trimming only applies to specified
URL paths.
E-mail address. You can define the email address that is shown when My Site notification email
messages are sent.
Secondary owner. You can define a secondary owner for personal sites. This is useful when the owner
of the My Site has left and the account has been deleted. Typically, in such a case, the manager of the
owner becomes the secondary owner automatically, however if the manager attribute in Active
Directory is not set, the secondary owner specified in this setting will be applied.
Trusted My Site host locations
Like with on-premises SharePoint, SharePoint Online allows you to set additional trusted host locations for
My Sites if you have more than one farm or more than one user profile service application. In the case of
SharePoint Online, this setting is most useful if you want some users to have My Sites in SharePoint
Online, and some users to have My Sites in your on-premises SharePoint farm.
Audiences
In SharePoint Online, audiences are configured in a similar way to on-premises SharePoint deployments.
You can create audiences for the purpose of targeting content to specific collections of users by creating
an audience with one or more rules that match certain Active Directory users. Audience rules in
SharePoint Online can use Active Directory group membership, the manager attribute in Active Directory,
or SharePoint Online user profile properties to match users to be a member of the audience.
Note: My Site storage in SharePoint Online is fixed at 500 MB per My Site and cannot be
adjusted.
Additional Reading: For more information about My Sites in SharePoint Online, see
Manage My Site Settings at http://go.microsoft.com/fwlink/?Linkid=299775
For more information about audiences in SharePoint Online, see Manage audiences at

Scenario
The management team at Contoso wants to encourage all employees to use social features of the new
SharePoint 2013 intranet to improve communication and the sharing of information. In particular,
Contoso wants people to use their My Site as their primary workspace and their starting point for sending
and receiving information. Your role is to configure the SharePoint intranet to support these goals. First,
you will configure My Sites so that users can create their own personal sites on demand and use tagging
and sharing features. You will also create some global audiences so that the Contoso management team
can target information to particular teams.
Objectives
Create and configure My Sites.
Create and configure audiences.

Virtual machines: 20331B-NYC-DC-12, 20331B-NYC-SP-12
Password: Pa$$w0rd
Virtual machine: 20331B-NYC-DB-12
Password: Pa$$w0rd
Exercise 1: Configuring My Sites

Scenario
In this exercise, you will configure My Sites. You will create a new web application to host the My Sites.
You will create a service account for the web applications application pool, and you will configure DNS.
You will then create a My Site Host site collection in the new web application. After you create the My Site
Host site collection, you will configure the User Profile Service application My Site settings and complete
the configuration. Finally, you will create a My Site by using a different user account.
1. Configure a DNS record for the My Site web application
2. Create an application pool service account for the My Sites web application
4. Create and configure a new web application to host My Sites
5. Create a My Site host site collection
6. Enable self-service site creation for the My Sites host web application
7. Configure My Site settings for the User Profile Service application instance
8. Enable the User Profile Service Application - Activity Feed Job timer job
9. Test My Site creation by using a non-administrative user account
Task 1: Configure a DNS record for the My Site web application
Open DNS Manager.
Property
Setting
Name
mysites
IP address
172.16.1.21
12-18
Task 2: Create an application pool service account for the My Sites web application

Property
Setting
Full name
My Sites Application Pool
UPN logon
[email protected]
contoso\MySitesAppPool
Password
Pa$$w0rd
Selected
Selected
Register the CONTOSO\MySitesAppPool account you created in the previous task as a managed
account.
Task 4: Create and configure a new web application to host My Sites

Property
Setting
IIS web site name
MySites - 80
Port
80
Host header
mysites.contoso.com
Property
Setting
SharePointMySites - 80
CONTOSO\MySitesAppPool
All other settings
Accept default setting
Add a managed path named personal to the mysites.contoso.com web application.
Task 5: Create a My Site host site collection
mysites.contoso.com web application with the following properties.
Property
Setting
Title
MySite Host
URL
http://mysites.contoso.com
Template
My Site Host
Task 6: Enable self-service site creation for the My Sites host web application
On the Central Administration web site browse to the Web Application Management page.
Enable Self-Service Site Creation for the MySites - 80 web application with default settings.
Task 7: Configure My Site settings for the User Profile Service application instance
Browse to the Manage Profile Service: Contoso UPSA page (this is the service application
management page for the Contoso UPSA service application).
Configure the My Site settings for the Contoso UPSA User Profile Service application by using the
Property
Setting
My Site host location
http://mysites.contoso.com
All other settings
Leave blank or accept the default setting
Task 8: Enable the User Profile Service Application - Activity Feed Job timer job
Browse to the Timer Jobs page.

Enable the Activity Feed Job timer job associated with the Contoso UPSA service application.
Task 9: Test My Site creation by using a non-administrative user account
Switch to the 20331B-NYC-DB-12 virtual machine. If you are not already logged on, log on as

On the SharePoint site, browse to the users My Site.
12-20
Results: After completing this exercise, you should have configured My Sites and tested My Site creation
for non-administrative users.
Exercise 2: Configuring Audiences

Scenario
In this exercise, you will configure two new audiences, one for the sales team and another for the finance
team. You will map these audiences to security groups in Active Directory. You will then compile the
audiences and create a compilation schedule to ensure the audiences remain current. You will then enable
audience targeting on an announcements list, and add two announcements, each targeted at a different
audience. Finally, you will test the audiences are working correctly by viewing the site home page, which is
already configured to include a Content Query Web Part that displays announcements from the site
collection, and uses audience targeting to restrict announcements that are displayed.
1. Create and configure a new audience for the sales team
2. Create and configure a new audience for the finance team
3. Create a compilation schedule
4. Enable audience targeting for an announcements list
5. Create an announcement that targets the Sales audience
6. Create an announcement that targets the Finance audience
7. Test the audiences
Task 1: Create and configure a new audience for the sales team

Create a new audience with the following properties.
Property
Setting
Name
Sales Audience
Owner
Include users who
Satisfy all of the rules
Users
Members of the Sales security group.
Compile the audience.
Task 2: Create and configure a new audience for the finance team

Create a new audience with the following properties.
Property
Setting
Name
Finance Audience
Owner
Include users who
Satisfy all of the rules
Users
Members of the Finance security group.
Compile the audience.
Task 3: Create a compilation schedule

Modify the default compilation schedule to compile audiences at 1:00 A.M. every day.
Task 4: Enable audience targeting for an announcements list

On the SharePoint site, browse to the Announcements list.
Enable audience targeting for the Announcements list.
Task 5: Create an announcement that targets the Sales audience
On the SharePoint site, browse to the Announcements list.

Create a new announcement with the following properties.
Property
Setting
Title
Sales Announcement
Body
This is a sales announcement.
Target Audience
Sales Audience
Task 6: Create an announcement that targets the Finance audience
Create a new announcement with the following properties.

Property
Setting
Title
Finance Announcement
Body
This is a finance announcement.
Target Audience
Finance Audience
Task 7: Test the audiences
12-22
In Internet Explorer, navigate to http://sharepoint.contoso.com. Log on as [email protected] with

the password Pa$$w0rd.
On the SharePoint site, verify that the Finance Announcement announcement appears on the
home page, but the Sales Announcement announcement does not
Results: After completing this exercise, you should have created audiences and configured audience
targeting.
In this module, you learned how to plan for and create the User Profile Service, the different types of
profile import options available, and how to customize and control user profiles in SharePoint. You also
examined the requirements and process for configuring My Sites under the User Profile Service
application, discovered the permissions available to control social features, and identified the
configuration and use of audiences.
Review Question(s)
Question: What are the requirements for the farm account before configuring Active
Directory user profile synchronization?
Question: When should you create additional user profile properties?
Test Your Knowledge
Question
When would you need to configure trusted host locations?
When you need to configure My Sites to trust content, such as documents, stored
in another location.
When you have multiple farms, each with a User Profile Service application, but
users should only ever have one My Site.
When you want to add additional links to the My Site navigation bar.
When you need to publish My Site information into Active Directory.
When you need to specify additional sources for profile data.

13-1
Module 13
Configuring Enterprise Search
Contents:
Module Overview
13-1
Lesson 1: Understanding the Search Service Architecture
13-2
Lesson 2: Configuring Enterprise Search
13-13
13-20
Lesson 3: Managing Enterprise Search
13-26
13-35
13-38
Module Overview
Search has been a cornerstone of Microsoft SharePoint Products and Technologies since SharePoint Portal
Server 2003. Since those early days, the architecture of the search service has evolved through the Shared
Service Provider architecture to the service application architecture of SharePoint Server 2010. It has also
grown with the addition of FAST technologies. SharePoint Server 2013 continues this growth by rearchitecting the service and integrating many of the components that were intrinsic to FAST Search to
deliver a more robust and richer experience for IT staff and users.
In this module, you will learn about the new architecture of the Search service, how to configure the key
components of search, and how to manage search functionality in your organization.
Objectives
Describe the core architecture of the Search service and its supported topologies.
Explain the steps required to configure the Search service in an enterprise environment.
Describe how to manage and maintain a well-performing Search environment.
Lesson 1
Understanding the Search Service Architecture
13-2 Configuring Enterprise Search
Search is one of the most important services in SharePoint 2013, like it has been throughout the
SharePoint product development. This is because it enables users to quickly and easily find the content
held in SharePoint, both from SharePoint content databases and from external data sources, through the
Business Connectivity Service. In SharePoint 2013, the underlying architecture of Search has been
redeveloped, to provide a richer enterprise search experience for users and streamlined administration.
In this lesson, you will see how the new architecture components combine to deliver a more robust and
faster search solution, and the topology designs available for all sizes of SharePoint 2013 deployments.
Lesson Objectives
Describe the SharePoint 2013 Search architecture.
Describe the functions of:
The Crawl Component.
The Content Processing Component.
The Analytics Processing Component.
The Indexing Component.
The Query Processing Component.
The Search Administration Component.
Describe the supported search topologies in SharePoint 2013.
The Search Architecture

The Search service has been rearchitected in
SharePoint 2013. The architecture changes have
been made to ensure that Search offers a higher
level of redundancy for single and multiple farm
environments. One of the most obvious changes in
the new architecture is the inclusion of the FAST
technologies into the Search service. This enhances
search functionality and makes it easier for
solution architects to design and deploy a fullfeatured search solution in their organizations.
Search combines a range of elements on
application servers, which include:
Crawl Component
Content Processing Component
Analytics Processing Component
Indexing Component
Query Processing Component
Search Administration Component
Core Solutions of Microsoft SharePoint 2013
13-3
These components interact to complete search data ingestion to the search index and for query results
surfacing. To ingest data, the Crawl Component interrogates the content sources that you have
configured, either on the SharePoint farm or on external sources, such as Microsoft Exchange or Lotus
Notes. The crawled items are processed by the Content Processing Component to format them
appropriately to be stored on the index. Information from the Analytics Processing Component is used in
this process, to identify useful associated item information, such as previous user interaction. The data, or
artifacts, are written to the index, which is a series of files and folders that are stored on disk and referred
to, collectively, as the index file. The Query Processing Component receives queries from the Web Front
End (WFE) server, processes and sends the query to the Indexing Component, which returns result sets.
The Query Processing Component performs additional processing to aggregate and clean the results and
then sends the result sets back to the WFE to be rendered for the user. There are temporary and
permanent storage databases used throughout the process.
The Crawl Component

The Crawl Component is a part of the crawl and
content processing architecture, which comprises
the Crawl Component, the crawl database, and the
Content Processing Component. The crawl role is
responsible for crawling content sources to build a
search index. This means that the component
reviews each of the documents or pages in a
source location. The locations that can be crawled
by the Crawl Component include:
SharePoint sites (includes SharePoint 2013,

SharePoint Server 2010, Microsoft Office
SharePoint Server 2007, and Office SharePoint
Portal Server 2003)
File shares
HTTP URLs (non-SharePoint sites now available for anonymous access)
User profile sources (for example, Active Directory Directory Services)
Microsoft Exchange public folders
Lotus Notes (e-mail messages)
Documentum (requires installation of prerequisite software, such as the Indexing Connector for
Documentum)
Custom (line of business or other locations provisioned by custom connectors)
The Crawl Component delivers content from files and pages, together with their associated metadata, to
the Content Processing Component. The crawled items that are passed to the Content Processing
Component have associated properties, such as title and author. Crawl uses connectors, such as the Lotus
Notes Connector, to access content sources and retrieve data. These were known as protocol handlers in
previous versions of SharePoint Products and Technologies. The properties are grouped, based on the
connector or IFiltera piece of code that enables the specific file formats to be indexed and thus be
searchable, now referred to as a format handlerused to crawl the content source; so, Microsoft Office
documents (for example, Word and Excel documents) would be grouped under Office, whereas properties
from websites would be grouped under Web. You can include the contents and metadata of crawled
properties in the search index file. To do this, you must map the crawled properties to managed
properties, because only these are included in the search index.
Note: You can find a complete list of default connectors for SharePoint 2013 at
The crawler itself does not complete document parsing; that function is provisioned by the Content
Processing Component.
The Crawl Component uses one or more crawl databases to temporarily store information about crawled
items and to maintain a crawl history. The database holds information such as the last crawl time, the last
crawl ID and the last crawl update type. Information about content sources, such as their schedules and
locations, are synchronized to the registry on crawl role servers from the search administration database.
Content Processing Component

When the Crawl Component forwards content and
metadata, the Content Processing Component
performs tasks on the content to prepare it for the
search index file. The search index works with
processed content, called artifacts. The Content
Processing Component tasks include parsing
documents, property mapping, and linguistics
processing. The latter detects language and
extracts language-based entities. The Content
Processing Component also writes information
about the URLs into the link database, which holds
information about links rather than content.
Including and excluding file types
The Content Processing Component can only process file data if the file type (extension) is included in the
list of available file types on the Manage Files Types page and the crawl server has the appropriate format
handler installed. By default, some file types, such as email messages with a .eml extension, are supported.
The default format handlers focus on content, so while a Microsoft PowerPoint .pptx format appears on
the Manage File Types list by default, the Microsoft PowerPoint .pps presentation file does not.
Note: You can view a full list of available file types, their extensions, and their default status
on the Manage File Types page listing at http://go.microsoft.com/fwlink/?Linkid=299778
Custom extractors
If you need greater granularity in your content processing, you can implement custom entity extractors.
An entity is just a word or phrase that may be of significance to your organization, such as a product
name or department names. In order to facilitate processing this content for the search index, you must
create and deploy your own customer entity extraction dictionary.
There are four extraction options available for identifying entities, as shown in the following table.
Custom entity extractor /
dictionary
Description
Word Extraction
Case-insensitive, maximum five dictionaries.

Example: the entry "vest" would match "vest" and
"Vest", but not "vestige".
Word Part Extraction
Case-insensitive, maximum five dictionaries.

Example: the entry "vest" would match "vest", "Vest"
and within "vestige".
Word Exact Extraction
Case-sensitive, maximum one dictionary.

Example: the entry "vest" would match "vest", but
not "Vest" or "Vestige".
Word Part Exact Extraction
Case-sensitive, maximum one dictionary.

Example: the entry "vest" would match "vest" and
within "vestige", but not "Vest".
13-5
Custom dictionaries are created as comma-separated value (.csv) files and then imported into SharePoint
2013 by using the Windows PowerShell cmdlet:
Import-SPEnterpriseSearchCustomExtractionDictionary SearchApplication $searchApp
Filename <Path> DictionaryName <Dictionary name>
Depending on which of the four dictionary types that you want to import, you must use one of the
following for the <Dictionary Name> element:
Microsoft.UserDictionaries.EntityExtraction.Custom.Word.n [where n = 1,2,3,4 or 5]

Microsoft.UserDictionaries.EntityExtraction.Custom.ExactWord.1
Microsoft.UserDictionaries.EntityExtraction.Custom.Wordpart.n [where n = 1,2,3,4 or
5]
Microsoft.UserDictionaries.EntityExtraction.Custom.ExactWordpart.1
Analytics Processing Component

One of the major changes to the search service is
the inclusion of web analytics functionality. This
was previously a separate service application in
SharePoint Server 2010. The new Search Analytics
function analyzes both the crawled items and how
users interact with search results; these are entitled
Search Analytics and Usage Analytics.
Search Analytics
The search analytics information is used to
improve search relevance and to create search
reports, recommendations, and data links. This
information is then returned to the Content
Processing Component for storage in the search index.
Information about search activity, such as the number of search clicks from a search results page, helps to
improve the relevance of the search results by analyzing previous user activities. This information is stored
in the link database. This information is then further analyzed by a series of sub-analyses. The following
table shows the sub-analyses that act on Search Analysis results.
Analysis
Description
Anchor text processing
Anchor text processing analyzes how content items

interlink. The analysis results add ranking points to items to
increase their relevance in the search index.
Click Distance
Click Distance calculates the number of clicks between an

authoritative page, such as a top-level site, and the items in
the search index. You can define Authorative pages in
Central Administration. Again, this adds ranking points to
improve search relevance in the search index.
Search Clicks
This uses information about which items users click in

search results to boost or demote items in the search index,
which is stored in the Link database.
Social Tags
This analyzes social tags input by users. These are not used
to improve ranking by default, but you can use these to
create custom search experiences.
Social Distance
This calculates the relationship between users who use the

Follow Person feature, to increase the relevance of People
Search by social distance.
Search Reports
This aggregates data, which is then stored in the Analytics

reporting database. It then generates search reports,
including:
Number of queries.
Top queries.
Abandoned queries.
No result queries.
Query rule usage.
The report information is saved in the Search service
application as part of the service application, and not with
the items in the search index. This means that you will lose
the reports if you delete the service application.
Deep Links
This uses search results usage clicks to identify the most

popular subpages on a site, which then display as
important site shortcuts accessible directly from the search
results.
Usage Analytics
Usage analytics analyzes usage events, such as views from the event store. When a user completes an
action, such as viewing a page, the event is collected and stored in usage files on each WFE server. This
information is pushed to an event store where it is stored until it is processed by the Analytics Processing
Component. The results are then returned to the Content Processing Component to be included in the
search index. The usage events that are analyzed include:
Views.
Recommendations displayed.
Recommendations clicked.
The following table shows the sub-analyses that act on Usage Analysis results.
Analysis
Usage counts
Description
The Usage counts analysis analyzes events, such as views. The
analysis checks the overall number of times that an item is
opened by any means, not just from a search result page. You
can set the analysis retention value as any number between one
and 14 days (14 days is the default value). The statistical data is
aggregated at the following levels:
Site level
Site collection level
Tenant level (SharePoint Online only)
Usage events are kept on disk for the retention value (the
default value is 14 days) and are then deleted. Every day, the
previous full day of Usage counts data is analyzed. The counts
are added to the search index items to improve relevance. The
analysis is also stored in the Analytics reporting database, where
this information can be used to display popular site items.
Recommendations
The Recommendations analysis creates recommendations

between items based on user activity patterns. To improve
relevance, the analysis calculates inter-item relationships and
adds the information to the search index items. You can use this
information to provide recommendations based on usage by
other users. This information is stored in the Analytics reporting
database.
Activity ranking
Activity ranking tracks usage events to improve search relevancy.

If an item has a high view usage, it will get a higher activity rank
score. The analysis identifies trends, so that older items, which
have just had more time to amass views, do not automatically
get a higher ranking than newer items, which are getting a
larger number of recent hits.
13-7
The Analytics Processing Component generates an Excel report that shows popularity trends and a listing
of most popular items, by view.
Index Component
The search index is a set of files that are stored in
separate folders on a server. The Content
Processing Component processes items
provisioned by the Crawl Components, maps
crawled properties to managed properties, and
formats these as artifacts that can be stored on the
search index. The indexes can include:
Full-text indexes.
Indexes of the managed properties (marked as

retrievable or queryable).
An index for attribute vectors.
Numeric indexes.
Because the Search Index can be a very large file, you can divide it into index partitions to improve
performance and management. An index partition is a logical portion of the entire search index.
The index comprises the Index Component, index partitions, and index replicas, which are described as
follows:
Index Component. This is used both in the content ingestion process and in the content querying
process. For the former, the Indexing Component receives items from the Content Processing
Component and writes them to the index file. For the latter, it receives queries from the Query
Processing Component and returns the result sets that are applicable to the query.
The Indexing Component is also responsible for much of the index content management. For example,
it will physically reorder index content if changes to the index architecture are triggered by the Search
Administration Component.
Index Partition. This is a logical portion of the entire search index; the index is the aggregated result
of all of the index partitions.
Index Replica. This is a physical copy of an index partition. Replicas can be either a Primary Replica or
a Secondary Replica. The Primary Replica is contacted by the Content Processing Component to write
new items to an Index Partition. Secondary Replicas are read-only copies of the same data, which are
used to provision results.
You can scale you search index in two ways:
You can add Index partitions to manage increasing search content volume. For example, in a farm
with three index partitions, each index partition contains one-third of the entire search index.
You can add Index replicas in an index partitions to manage high query loads or to provide increased
fault tolerance. Each index partition has one or more index replicas. For example, in a farm with one
index partition that contains three index replicas, each index replica serves one-third of the total
queries.
Query Processing Component

The Query Processing Component, which sits
between the Index Component and the search
front-end client, handles processing when a user
executes a search query and processes the results
to be returned. When the Indexing Component
or another search providerreturns a result set,
the Query Processing Component performs any
additional processing that is required.
The Query Processing Component performs some
linguistic processing to maximize query efficiency
and effectiveness, such as:
Word stemming. Stemming returns words

closely related to or stemming from another word. For example, the stemmer relates words such as
jumping, jumped, and jumper to the verb to jump.
Word breaking. This refers to the breaking of words that are linked by some form of hyphenation; for
example, the term server-based is linked by a hyphen. In this case, word breaking returns both
server and based, with higher relevance given to an item with both present.
The query processing workflow is as follows:
13-9
The Query Processing Component receives a query from the search front-end client and processes to
maximize precision, recall, and relevancy. These actions include:
o
Applying Web Part transformations.
Note: Query transformations in a Web Part are most often used to specify the result
sources to which queries should be sent. Therefore, a query transformation may ensure result sets
returned from a content source match content type, such as Images. You would create a Web
Part that has a query transform that changes any query run in that Web Part to use your new
Images result source.
o
Initiating query rules.
Applying transformations on result sources.
Parsing the query and creating a query syntax tree.
Performing linguistic processing, such as word breaking, stemming, spelling checking, and
thesaurus application.
Appending user-access information.
The processed query is then sent to the Indexing Component or external source.
The result sets are returned from the Indexing Component. These are aggregated and are again
processed to remove duplicates by:
Evaluating the search results against result types.
Applying any additional required security trimming.
The processed results are then sent to the WFE, so that they can be rendered for the user.
Search Administration Component

The Search Administration Component runs
system processes required for search. It is
responsible for search provisioning and managing
topology changes, and it coordinates interaction
between the other search componentsContent
Processing, Query Processing, Analytics Processing,
and Index Component.
The Search Administration database, which stores
the Analytics settings, also stores the configuration
elements relevant to the Search Administration
Component. These elements include:
Search topology
Crawl rules
Query rules
Managed property mappings
Content sources
Crawl schedules
The Search Administration database no longer stores access control lists (ACLs), like it did in previous
versions of SharePoint. This information is now stored in the Search index.
The search processes provisioned by the Search Administration Component include:
NodeRunner.exe. This is the process that hosts the search components. You may have multiple
instances of NodeRunner.exe on a single server, each of which hosts one search component.
Host Controller. This is a Windows Service that supervises NodeRunner.exe process instances on a
server system. If any of the NodeRunner.exe processes fail, the Host Controller detects this and
restarts the process automatically.
MSSearch.exe. This is the Windows Service that hosts the Crawl Component.
Search Topology Design

SharePoint 2013 search topology design is a
function of scale and content volatility. The search
architecture components perform functions that
consume application server resources (storage,
processor, and memory) and network bandwidth.
There are no two environments that are identical,
but for design purposes, search implementations
are categorized as small, medium, and large
enterprise deployments. Common to all is the
need to ensure adequate performance and
resilience. These design criteria must be driven by
organizational requirements and service level
agreements for availability, performance, and capacity.
Reference Links: Microsoft provides guidance Visio diagrams for topology design at
Small enterprise
13-10
A small enterprise deployment is defined by Microsoft as one that provisions search functionality for up to
10 million items. As part of your planning, you should estimate the number of search items that you need
to index. You should also ensure that you fully understand the SharePoint site content volume and the
volumes of searchable content that may be included from external data sources, because these may be
considerably larger than you anticipate. These volumes will also be hugely affected by criteria such as
crawl depth, which is covered in the next lesson.
A small enterprise environment often delivers multiple SharePoint services from a single physical server.
This does not mean that a small enterprise should run on a stand-alone server; this configuration should
only be used for development and testing. However, you may have a web server providing additional
application server functions. Many organizations tend to start small and then scale out services and
service applications as they identify performance or capacity bottlenecks. Clearly, you should make every
effort to plan your topology to minimize bottlenecks, but they are a feature of an IT professionals
working life. This makes it important to monitor all servers and service applications across your SharePoint
2013 deployment.
13-11
You need to ensure that you provision the right level of fault tolerancethe ability to maintain search
provision in the case of a failure, such as a disk or processor crashfor your operation. You also need to
guarantee component availability, so you should deploy multiple crawl, content processing, analytics
processing, query processing, and Search Administration Components. You should also deploy primary
and secondary index replicas to deliver an effective level of fault tolerance for your index.
Medium enterprise
A medium enterprise is defined as one that can manage up to 40 million search items. This usually means
that you dedicate servers to specific search functionsscaling out, rather than scaling up.
As the size of the index grows, you should review the number of servers running the Query Processing
Component and storing the search index. Additional servers can deliver greater throughput processing
and therefore better performance for users.
All search contentcrawl, indexes, search administration, and linksare stored on your database server. If
this is managed by your organizations database administrator (DBA), you should coordinate with the DBA
to help ensure fault tolerance and performance through the implementation of SQL Server features such
as Always On.
Note: SQL Server functionality that you should consider as a SharePoint 2013 administrator
is covered in Module 5, Installing and Configuring SharePoint Server 2013 of this course.
General guidance on when to scale out search components is difficult to give; your search performance
requirements and content volatility will be different from those of another, similarly sized organization.
That said, there are some advisory rules available from Microsoft:
Deploy and configure one additional index partition per 10 million items.
Always use two Query Processing Components for redundancy.
When you have more than 80 million items, increase the number of Query Processing Components to
four.
Deploy and configure one additional crawl database per 20 million items.
Deploy and configure one additional link database per 60 million items.
Deploy and configure one additional analytics database for each 500,000 unique items viewed per
day or for each additional 10 million items.
Always deploy two Search Administration Components for redundancy.
Large enterprise
A large farm is defined as one that provides search services for 100 million items. For a large farm, you
should scale out based on the preceding advisory guidance. When working with enterprise search
environments, you must monitor changes in search performance metrics. Performance on very large
deployments can be more complex than simply following the advisories for medium-sized enterprise
scaling.
You should monitor and take remedial actions for the following:
Increasing crawl times or crawl content freshness issues. You should use the Crawl Health Reports to
identify changes in performance and any associated bottlenecks. To improve crawl time and index
freshness, you may add more crawl databases and Content Processing Components for result
freshness. Be sure to identify any system contention on servers; the recommended minimum RAM for
a dedicated indexing servers (systems running the Indexing Component) is twice that of systems
running other search service components; a minimum of 16 GB RAM.
13-12
Increasing time for results to be returned to users. To improve query latency and query throughput,
you should consider increasing the number of search index partitions to reduce the number of items
on each partition.
Again, you must focus on increasing the resilience of your search environment by deploying additional
fault tolerance.
You may also assess the need for a search-specific farm deployment. For an organization that is heavily
dependent on search, it may be advisable to separate searches that can be shared across farms as a
service application, to better manage server and network traffic and performance.
Lesson 2
13-13
Enterprise search configuration is a potentially complex undertaking. The search service has the potential
to open your organizations content and make it available to your users in a way that is both enabling and
secure.
That said, search can also consume a lot of system resourcesstorage, processing, and network
bandwidthif the architecture components are not effectively configured and managed.
Lesson Objectives
Describe the function of content sources.
Explain how to configure content sources.
Explain how to plan and configure content crawling.
Describe the configuration options and components of a Search Center.
List some of the core optimization options for a search service.
Discussion: Search Experiences

Search is a key business enabler for many
organizations. In this discussion session, share your
experiences of working with and administrating
SharePoint Search. Areas of interest include:
Use of search in your organization.
Search management in your organization.
The extent of search organization; do you

extend search to your line-of-business data
sources?
Do you provide a Search Center for users?
You experience of deploying and administrating SharePoint Search.
Planning Content Sources

Content sources and connectors are the items that
influence crawl planning and provision the
configuration options. Core to information
crawling for the search service are content sources.
Planning content sources

When you plan a content source, you must define
the location of the content that you want to crawl
for inclusion in your search index, as well as crawl
parameters, such as the crawl schedule and depth.
13-14
The default content source includes all your local

SharePoint sites. You can configure this content
source to establish the crawl parameters for a web application that you associate with a Search service
application. If you only need to provision search for your SharePoint environment, you can have a single
content source. For most enterprise environments, you will need to plan for additional sources. This is
because you will probably need to include other line-of-business systems, file shares, and social
information resources, particularly if you are using People Search in a complex environment where user
information may be managed in a number of locations.
When planning for additional content sources, you should consider the following:
What do you need to crawl? You need to identify what you need to crawl. This may sound obvious,
but a lack of knowledge of the content that your business users need to effectively complete their
work can often be a major problem for search implementations. You need to have users and
stakeholders identify the content that they need and its location.
What platforms do you need to crawl? When you know what your users need and where it is, you can
then identify the business platforms that you need to crawl. You must ensure that you have the
appropriate connectors for the target environments. For example, if you have email content on a
Lotus Notes server, you will need to implement the Lotus Notes Connector.
How often do you need to crawl these content sources? Not all content changes at the same rate. For
static content, you may not need to crawl the content source on a daily or even a weekly basis;
whereas for highly volatile content, you may need to crawl on a more frequent basis. The crawl
process requires processor effort and can increase network traffic, so you must manage these
resources, like you should for any solution deployment.
How much do you need to crawl? It can be tempting to just crawl everything; at least you will not miss
anything important. However, by doing so, you may consume resources and unnecessarily increase
the size of your search index. For example, if you need to crawl a file share, you should consider
whether you need to crawl all subfolders of the root folder as defined by your content source. As you
configure security on a least privilege model, you should only crawl the information that your users
need.
How important is your information? When defining when you need to crawl and the depth of crawl,
you should establish how important the content source information is to your users. You may need to
prioritize some content because it is important to business users.
All of these planning elements should be considered because they will help you better manage system
and administrative resources. You can create as many content sources as needed in a Search service
application, and each of these can have up to 100 location start addresses. However, keep in mind that
you, or your colleagues, will need to administer all of this information.
13-15
Although you can have many location start addresses in a single content source, you can only have one
type of content per content source. For example, if you want to crawl file shares, you will need to have a
specific content source for this type of content; you cannot have a file share start address and a
SharePoint site start address in the same content source. The possible content sources relate to the
possible connectors as outlined in Lesson 1, The Crawl Component.
Configuring Content Sources

After you complete planning for your content
sources, you must configure your sources based
on the business requirements that you have
gathered.
You configure content sources from your Search
service application Search Administration page.
From here, you can manage all of the content
sources that you currently have, and you can add
new ones as necessary.
The page is designed to make it easy to translate

your business requirements for search into an
effective search source configuration. You first
have to name your content source. It is a good idea to make this meaningful. Remember that you are
creating a content source that is associated with a type of contentSharePoint sites, websites, file shares,
and so onso you should not insert a name that only references a specific content address location.
The next area of configuration requires the type of content, and therefore the connector, that you want to
use. The default list includes:
SharePoint sites.
Websites.
File shares.
Exchange public folders.
Line of business data.
Custom repository.
This reflects the functionality currently configured for your Search service.
Additional Reading: If you need Lotus Notes email access, you must ensure that the
connector and any other required software is already installed and deployed. For a step-by-step
guide for installing and provisioning the Lotus Notes connector for SharePoint 2013, see
Configure and use the Lotus Notes connector for SharePoint Server 2013 at
You can then start to list the start addresses for your target content. For example, if you want to crawl the
entire Litware Inc. site, you might insert http://litware. However, if you only want a portion of that site,
such as the product site, you would enter http://litware/products. You can insert up to 100 start addresses
per content source.
After you create a source and specify the crawl start addresses, you can further refine the crawl by adding
specifications for the depth of the crawl, a schedule for the regularity of the crawl, and its priority. The
depth of the crawl can be limited to the root of the actual address; therefore, you could limit the
http://litware example by specifying that only content at this level in the hierarchy be crawled.
13-16
Note that this configuration parameter reflects the action to be taken for all the start addresses you have
included in the content source. If you have different requirements for some sites, you will need to add
additional content sources. However, you cannot crawl the same start addresses by using multiple content
sources in the same Search service application. For example, if in the example you choose to crawl
http://litware and all of its subsites, you cannot then add a new source to crawl http://litware/product on
a different schedule.
SharePoint 2013 has introduced continuous crawling, which is a new option for managing content source
crawls for SharePoint sites. Continuous crawling is an additional option over the existing incremental and
full crawls, so you can still configure incremental and/or full crawls as you would in SharePoint Server
2010. If you enable continuous crawling, you do not configure incremental or full crawls. When you select
the option to crawl continuously, the content source is crawled every 15 minutes. This is the default
setting, but this can be changed by using the Set-SPEnterpriseSearchCrawlContentSource cmdlet in
Windows PowerShell. When continuous crawling is selected, the crawler receives changes from SharePoint
sites and pushes them to the Content Processing Component. Continuous crawling combined with
performance improvements in the Content Processing Component means that newly crawled content can
be processed and available to be searched far more quickly. It also makes it possible to process changes
while a full crawl is starting, which allows you to see results before the full crawl completes. This is very
useful in ensuring that the search index for content sources that use the SharePoint sites content source
type are kept fresh.
The final configuration option for content sources is to set the crawl priority to either Normal or High.
This is a relative weighting; therefore, if the two crawls overlap, a High priority content source takes
crawler priority over a Normal priority source.
Planning and Configuring Crawl Rules

After you plan and configure your content
sources, you can manage the way that your crawls
execute by implementing crawl rules at the Service
Application level. You can apply a crawl rule to a
URL or a set of URLs in order to improve the
performance of your search indexing. Search
indexing and crawling content sources can
consume a significant portion of network
bandwidth. Equally, if you crawl a large amount of
unnecessary content, you will increase the
processing load on your Content Processing
Component and the server on which it is
configured.
It is not always easy to identify the content that you need to crawl when you first start planning your
search environment, so planning your search deployment, and specifically the crawling, is a journey,
rather than a destination. You need to undertake ongoing reviews and analysis of the SharePoint 2013
query and crawl logs to identify the search focus of your users, to work on maximizing efficiency for
popular areas and to minimize crawl effort for content sources that are little used.
As you find content that no longer needs to be crawled, you can configure crawl rules to exclude those
content source URLs. This is the most obvious rule to implement, based on log analysis. There can be
more subtle changes that you should implement. For example, you may find that a page or a URL
13-17
contains links that are frequently used, although the URL itself does not have any relevant information. In
a case such as this, you can implement a rule that crawls the links, but not the URL itself.
Often URLs contain question marks to indicate a query. These are often referred to as query strings or
complex URLs. You can implement crawl rules to instruct SharePoint Search to crawl complex URLs. You
should only do this if you are confident that the locations to which a query URL redirects the crawler
contain relevant content.
Crawl security is an important consideration when you implement a search solution. As part of your
deployment, you will have a Default Content Access service account to crawl content sources. The access
permissions for this account are commonly Full Read permissions for content that is outside the local
farm, with Full Read permissions automatically configured for content databases in the local farm. With
crawl rules, you can implement a different content access account for a specific URL. Additionally, you can
include a client certificate to provide access to a specific URL for claims-based authentication.
For SharePoint sites only, you can configure content to be crawled as HTTP pages. This can enable the
crawler to crawl content that is behind a firewall or is otherwise restricted. This is not a means of
bypassing security, because all content access continues to be restricted based a users permissions as
defined in the datas access control list (ACL). This is implemented as part of the SharePoint 2013 security
trimming functionality.
Search Center
A Search Center site is the top-level site of a site

collection. The goal of a Search Center is to
provide site collection users with a central search
facility. You can create a Search Center from which
your users can submit search queries by deploying
a site using either the Enterprise Search Center
template or the Basic Search Center template.
When you create a Search Center, you must grant
access permissions to your users and user groups.
The difference between building a Search Center
based on the Enterprise Search Center template
and the Basic Search Center template is the ability
to customize the user experience. In an Enterprise Search Center, you can author you own site pages;
whereas in a Basic Search Center, you can only edit the search and search result pages delivered by the
template. The Enterprise Search Center template is available with SharePoint Server 2013-Standard Edition
and SharePoint Server 2013-Enterprise Edition.
Note: To provision an Enterprise Search Center, you must enable the SharePoint Server
Standard Site Collection and SharePoint Server Standard Publishing infrastructure features.
In Enterprise Search Center, SharePoint 2013 provides:
A default search home page (default.aspx).
A default search results page (results.aspx).
A number of search verticalspreset result categories, such as people or videos pages to display:
o
People Search results (peopleresults.aspx)
Conversation search results (conversationresults.aspx)
Video search results (videoresults.aspx)
13-18
An advanced research page (advanced.aspx) where users can refine their search queries by applying
query text restrictions; for example, by applying an exact phrase match.
These .aspx pages contain Web Parts that the search administrator or the site collection administrator can
configure to deliver a more organization-specific search experience.
For the search verticals, the Search Results Web Part is configured to specific local result sources, such as
the Local People Results (System) and the Local Video Results (System).
Optimizing Your Search Service

This module has provided advice on how to
deploy an effective and efficient search
environment. The following are additional best
practices that you should note when developing
your search solution.
Maximize use of SharePoint sites

SharePoint is designed to maximize search
efficiency. Where possible, you should concentrate
your search sources on SharePoint 2013, rather
than having it dispersed across diverse sources.
You should also concentrate this rich data in
related site structures to minimize unnecessary
crawl effort.
Know what you should crawl
Clearly, you should only crawl data that is likely to be relevant to user search queries, and you can identify
these, as previously noted, through analysis of historical logging statistics. From the outset, you can
identify content that you should not crawl, such as:
Backup files.
Log files.
Archive files, which do not contain fresh or pertinent information.
Manage crawl depth
You can limit the crawl depth for your various content sources. The location that you configure is a start
address; for example, you may configure only the folder on the start address of a file share, so that no
subfolders would be included in the crawl. This can help you to manage the size of the search index file.
You can also configure crawl rules to manage the crawl process, minimizing processing overload and the
size of the search index file. To improve performance, you can scale out the Crawl Component by adding
additional instances of the Crawl Component.
Use natural language hierarchies
Although IT staff commonly use abbreviations to name folders, this nomenclature can often be
meaningless to users. Both for navigation and for search ranking, it is a good idea to use natural words
rather than abbreviations to assist users. These do not need to be verbose, because you do not want to
start creating unnecessarily long URLs, but they should be understandable. SharePoint Search analyzes
URLs and file metadata linguistically, so consistent and clear naming will help you to develop effective
content ranking.
Use metadata
13-19
Too many SharePoint deployments have provisioned little more than organized file shares for their users.
Metadata has always been one of the key benefits offered by SharePoint to support content surfacing.
You should encourage the use of consistent and clear metadata by your users when creating files. The use
of term sets and tagging can enhance search effectiveness when indexing content; therefore, it helps to
deliver more accurate results sets against user queries.
Use consistent language
If possible, you should not mix languages on a single site. Search tries to detect language automatically,
so if there are multiple languages on a site, it will default to the language of the site where the content is
stored, which may not be the best choice. You should also use a single language for URLs and metadata,
because using multiple languages in metadata can also cause confusion. For the latter, you should deploy
single language term sets.
Use authoritative pages
An authoritative page is one that the search administrator specifies as containing relevant information. A
search result from an authoritative page gets a higher ranking when it is returned by a search query. You
can specify three tiers of authoritative pagesMost authoritative pages, Secondary-level authoritative
pages, and Third-level authoritative pageson the Authoritative Pages link from the Search
Administration page. You can also specify Non-authoritative Sites from this page for sites that you want to
have a lower ranking in a results set.
Additional Reading: You can find out more about configuring Authoritative Pages at

Scenario
13-20
As part of the ongoing SharePoint 2013 deployment and configuration process, the IT team at Contoso
wants to roll out search functionality. Currently, some content is stored on the new SharePoint 2013
intranet, and some content is still stored on network file shares. The search functionality must enable users
to find the content they need, regardless of whether it is stored on a SharePoint site or a file share. Your
task is to provision the search service and then configure content sources and crawl schedules to index the
local SharePoint sites and the required network file shares. You then need to create a Search Center site
collection to verify that the search functionality behaves as expected.
Objectives
Provision a Search service application.
Create content sources and configure crawl schedules for file shares.
Configure content sources and crawl schedules for local SharePoint sites.
Create a search center by using the Enterprise Search Center site collection template.
Lab Setup
Passw0rd: Pa$$w0rd
All Windows PowerShell cmdlet syntax is available is available to cut and paste in the Lab Answer Key
document.
Exercise 1: Configuring the Search Service Application

Scenario
In this exercise, you will create and configure a new Search service application instance. First, you will
create new domain accounts for:
The Search service.
The Search Admin Web Service application pool.
The Search Query and Site Settings Web Service application pool.
The default content access account.
You will register the first three of these accounts with SharePoint as managed accounts. Finally, you will
provision a new instance of the Search service application.
1. Create service accounts for the search service
2. Register the service accounts as managed accounts
3. Provision a Search Service application instance
4. Configure the default content access account
Task 1: Create service accounts for the search service
13-21
Log on to the DC1 virtual machine as Contoso\Administrator with the password Pa$$w0rd.
Create the following users in Active Directory.

Full name
User name
Password
Password
options
SPSearch
[email protected]
Pa$$w0rd
Password
never
expires
SPSearchQuery
[email protected]
Pa$$w0rd
Password
never
expires
SPSearchAdmin
[email protected]
Pa$$w0rd
Password
never
expires
SPContentAccess
[email protected]
Pa$$w0rd
Password
never
expires
Task 2: Register the service accounts as managed accounts

Pa$$w0rd.
Create new SharePoint managed accounts for the following principals:

o
[email protected]
[email protected]
[email protected]
Task 3: Provision a Search Service application instance
Create a new Search Service application instance with the following properties:
Name the new service application Contoso Search.
Set the search service account to CONTOSO\SPSearch.
Create a new application pool for the Search Admin web service named SharePointSearchAdmin.
The application pool should use the CONTOSO\SPSearchAdmin managed account.
13-22
Create a new application pool for the Search Query and Site Settings web service named
SharePointSearchQuery. The application pool should use the CONTOSO\SPSearchQuery managed
account.
On the Manage Service Applications page, verify that the search configuration process has created
three service applications:
A Search service application.
A Search Administration Web Service service application.
A Usage and Health Data Collection service application.
Task 4: Configure the default content access account
Change the default content access account of the Contoso Search service to
CONTOSO\SPContentAccess.
Results: After completing this exercise, you should have created and configured a new Search service
Exercise 2: Configuring a File Share Content Source

Scenario
In this exercise, you will configure a content source for a remote network file share. You will configure the
start location for the content source, and create full crawl and incremental crawl schedules. Next, you will
configure permissions on the file share, so that the content access account has read access to any content
on the file share and can read permissions on files and folders. You will also add the content access
account to the Manage auditing and security log policy, so that the search service can index audit
information on the content. Finally, you will run a full crawl and verify that the file share was indexed
successfully.
1. Create a new content source
2. Grant access to the audit logs
3. Configure permissions on the file share
4. Run a full crawl
Task 1: Create a new content source

Pa$$w0rd if you are not already logged on.
In the service application settings for the Contoso Search service, create a new content source
named IT Share. The content source should crawl the file share at \\NYC-DB1\ITShare and all its
subfolders.
Configure a crawl schedule to perform an incremental crawl on the content source every day at
3:00 A.M.
Configure a crawl schedule to perform a full crawl on the content source once a week at 2:00 A.M.
every Saturday.
Task 2: Grant access to the audit logs
13-23
Switch to the 20331B-NYC-DB-13 virtual machine and log on as CONTOSO\Administrator with the
password Pa$$w0rd.
Use the Local Group Policy Editor to provide access to the audit logs for SPContentAccess.
Task 3: Configure permissions on the file share
On the 20331B-NYC-DB-13 virtual machine, grant the [email protected] account read

permissions on the E:\ITShare folder.
Task 4: Run a full crawl
Start a full crawl on the IT File Share content source.
After the crawl completes, view the crawl log and verify that the crawl completed without errors.
Note: The crawl may take two to three minutes to complete. Click Refresh periodically
until the Status column shows Idle.
Results: After completing this exercise, you should have configured a content source for a network file
share.
Exercise 3: Configuring a Local SharePoint Content Source

Scenario
In this exercise, you will configure a content source for local SharePoint sites. This content source is
created by default when you provision the search service application, but you still need to at least
configure crawl schedules. In this case, you will configure the content source to use the new continuous
crawl feature for local SharePoint sites. You will also configure a full crawl schedule to run during periods
of low demand. Finally, you will perform a full crawl and verify that the SharePoint sites were indexed
successfully.
1. Configure the content source
Task 1: Configure the content source

In the service application settings for the Contoso Search service, locate the Local SharePoint sites
content source.
Perform a full crawl on the content source.
Configure the content source to use the continuous crawl feature.
Configure a crawl schedule to perform a full crawl on the content source once a week at 2:00 A.M.
every Sunday.
After the crawl completes, view the crawl log and verify that the crawl completed without errors.
Note: The crawl may take two to three minutes to complete. Click Refresh periodically
until the Current crawl duration column is empty.
13-24
Results: After completing this exercise, you should have configured a content source for local SharePoint
sites.
Exercise 4: Creating a Search Center

Scenario
In this exercise, you will create a search center site to test your search configuration. First, you will create a
new managed path for the search site collection. Next, you will create the search center by using the
Enterprise Search Center site collection template. Finally, you will test your content source configuration
by running some queries.
1. Create a new managed path
2. Create a Search Center site collection
3. Test search functionality
Task 1: Create a new managed path
In the SharePoint sharepoint.contoso.com80 web application, create a new explicit inclusion

managed path named search.
Task 2: Create a Search Center site collection
In the SharePoint sharepoint.contoso.com80 web application, create a new site collection with
the following properties.
Property
Value
Name
Search Center
Description
Search results from across the Contoso enterprise
URL
/search
Template
Enterprise Search Center
Primary Site Collection Administrator
Task 3: Test search functionality
In Internet Explorer, browse to http://sharepoint.contoso.com/search. If you are prompted for

credentials, log in as CONTOSO\Administrator with password Pa$$w0rd.
In the search box, type How do I connect to a printer, and then press Enter.
Verify that the search returns a link to the FAQs.docx file in the file share that you configured.
In the search box, type Password policy, and then press Enter.
13-25
Verify that the search returns a link to the IT Policies and Procedures.docx file in the file share you
configured.
In the search box, type Fabrikam contacts, and then press Enter.
Verify that the search returns a link to the Customer Contacts list on the local SharePoint site.
Results: After completing this exercise, you should have created a search center and tested your content
source configuration.
Lesson 3
Managing Enterprise Search
13-26
Managing an enterprise search environment has been extended in SharePoint 2013. In previous versions,
the focus of search management has been at the service application level by search administrators.
Although this is still available, search management is now available more widely for site collection
administrators and site owners.
In this lesson, you will see how you can provision search management of a range of search components,
such as Query Rules and Result Types.
Lesson Objectives
Describe how to manage the search schema.
Explain the use and deployment of query rules.
Describe the use of result types.
Explain the function and management of display templates.
Describe the options for search navigation.
Explain the management of search engine optimization.
Discussion: Search Service Administrator vs. Site Collection Administrator

Search Configuration
What are your thoughts or experiences of using
site collection administrators to manage your
search service?
What training do you think should be given?
Will delegation really make it easier to

provision search services?
What issues do you see arising from this

administrative delegation?
Do you think you will delegate search

administration in your organization? Why?
Managing the Search Schema

The SharePoint 2013 search schema defines:
The items that can be crawled and indexed.
How items are indexed.
How results are rendered in search sites.
13-27
The search schema is used to map the

relationships between crawled properties and
managed properties. This is an essential search
feature, because users can only search on
managed properties; they cannot search on
crawled properties. In SharePoint 2010, you could
search on crawl properties. In SharePoint 2013,
this approach is deprecated, but the content is still available for full text query. The mapping in the search
schema can be one-to-many in both directions; crawled property to managed property or managed
property to crawled property.
When you first install SharePoint 2013, there is only one search schema, but you can create multiple
additional schemas. The initial search schema is available for editing in Central Administration. You can
create additional schemas at the site collection level, which means that farm administrators can delegate
some of the schema administration. Considering this structure, an organization can have an overarching
search schema but can offer search flexibility at the site collection level.
The model works on both on-premise and online SharePoint deployments; however, there is an additional
level in the structure for SharePoint Online. Tenant administrators inherit the search schema from the
Microsoft-provisioned Search service application, and they can override this schema. Below the tenant
level, site collection administrators can create site-specific search schemas, as per an on-premise
environment. It is worth noting that site owners can view the search schema, but not change it.
The configuration changes available for crawled properties, managed properties, or mapping at service
application level include:
Add.
Remove.
Change.
Delete.
At a site collection level, an administrator can:
Create new managed properties of type String. These cannot be defined as refinable or sortable.
Create new managed properties of type Yes/No.
Override existing mappings to managed properties.
Create aliases for managed properties.
13-28
SharePoint Server 2013 also introduces new settings that you can apply to managed properties, as shown
in the table.
Managed property setting
What it does
Available in
Searchable
Enables querying against the

content of the managed
property. The content of this
managed property is included
in the full-text index.
Site Collection Administration
Tenant Administration
Advanced Searchable
Settings
Enables viewing and changing

the full-text index that the
managed property is written to.
It also allows you to change the
context of the managed
property for the relevance rank
calculation.
Queryable
Enables querying against the

specific managed property, for
example Author or Title. The
managed property name must
be included in the query, either
specified in the query itself or
included in the query
programmatically.
Retrievable
Enables the content of this

managed property to be
returned in search results.
Enable this setting for managed
properties that are relevant to
present in search results.
Allow multiple values
Allows multiple values of the

same type in this managed
property.
Refinable
Active: Enables using the

property as a refiner for search
results in the front end. You
must manually configure the
refiner in the web part.
Latent: Enables switching
refinable to active later, without
having to do a full re-crawl
when you switch.
Sortable
Yes active: Enables sorting the

result set based on the property
before the result set is returned.
Yes latent: Enables switching
sorting to active later without
having to do a full re-crawl
when you switch.
Both options require a full crawl
to take effect.
Managed property setting
What it does
Available in
Alias
Defines an alias for a managed

property if you want to use the
alias instead of the managed
property name in queries and in
search results.
Token normalization
Enables returning results

independent of letter casing
and diacritics used in the query.
Complete matching
Queries will only be matched

against the exact content of the
property.
Mappings to crawled
properties
The list shows all the crawled

properties that are mapped to
this managed property.
Company name extraction
Enables the system to extract

company name entities from
the managed property when
crawling new or updated items.
The extracted entities can later
be used to set up refiners.
Custom entity extraction
Enables one or more custom

entity extractors to be
associated with this managed
property.
Query Rules
Query rules are new to SharePoint 2013. The
purpose of a query rule is to interpret the intent of
a query in order to provide the user who submits
the query with the best possible result set.
There are three key components of a query rule:
Query Conditions. These are the rules that

define the possible matches for the query.
Query Actions. These define the actions that

the search service takes when a match is
made.
Publishing Options. These define when the

query rule should be enacted.
13-29
Like much of search management, you can create query rules at the service application level and at the
site collection level, but you can also make query rules at the site level. This provides even greater
administration flexibility. The permissions required for each are as follows:
Search service applicationSearch service application administrator
Site collectionSite collection administrator
SiteSite owner
The rules created at these levels are available to:
Search service applicationAll site collections in web application that consume this service
application
Site collectionAll sites in the site collection
SiteThis site
13-30
There are several out-of-the-box query rules that are available. You can use these as models or templates
to create query rules specific to your organization or sites.
Implementing query rules
In SharePoint 2013, query rules can initiate multiple queries and multiple result sets. This differs from the
previous version of SharePoint, where a single query returned only one set of results. This is the core of
the intent of a query. A user query can trigger related queries where the users intention is extrapolated.
This triggering of multiple queries can offer a richer set of results, because all matching query rules can
generate results. The Query Orchestration Engine retrieves all the search result sets and organizes them
for presentation to the user through a Query Results Display template.
Query rule creation

Query rule conditions define the execution criteria for a query rule. When you create a query rule, you
define the context and conditions for the rule to apply.
The context defines the result source or sources to which you want the rule to apply. The Query
Conditions setting provides operators that define the query rule execution, including:
Query Matches Keyword Exactly. The query rule executes when a query exactly matches a word or
phrase.
Query Contains Action Term. The query rule executes when a query contains a term that indicates
something that the user wants to do.
Query Matches Dictionary Exactly. The query rule executes when the query exactly matches a
dictionary entry.
Query More Common in Source. The query rule executes if the query was frequently issued by users
on a different result source that you specify.
Result Type Commonly Clicked. The query rule executes if other users frequently clicked a particular
result type after they typed the same query.
Advanced Query Text Match. You can specify a regular expression, a phrase, or a dictionary entry that
will cause the query rule to execute.
You can specify multiple conditions for a query by selecting the Add Alternate Conditions check box.
Query rule actions
When your query rule has a match, you need to specify an action that should occur. There are three types
of actions:
Assign a promoted result to the query. This promotes the result in much the same way that was
available through Best Bets with SharePoint 2010 and Visual Best Bets with FAST Search 2010.
Because there is a single enterprise search engine, there is no longer a differentiation between the
two like there was in SharePoint 2010.
13-31
Create and display a Result Block. A Result Block is the results from several queries that are rendered
in a single group. To configure the actions for a result block, you use the Query Builder. This enables
you to build the query through an interactive interface and to test the results. Result blocks specify an
additional query to run and how to display results. You can include the results above those returned
by core results, or interleaved by ranking. The Result Block is ranked as a block, rather than as
individual items within the block.
Change the query that returns the core results. You can change the original end-user submitted query.
You can change the query terms, add additional terms, or apply an XRANK formula to the query.
For each query rule, you can add multiple actions, such as best bets or results blocks.
Query rule publishing
Publishing options for a query rule determine when it will be used by setting a start and stop date.
Alternatively, you can have the rule run permanently. You can also set a review date, specifying that you
should review the query rule at a specified time; of course, you may decide to continue using the rule at
this time. This is most commonly used in time critical scenarios, such as on e-commerce sites where
product availability or promotions change on specific dates.
Managing Result Types

SharePoint 2013 includes a new framework for
presenting search results to end users called result
types. These have several elements that let you
define which user interface should be used to
display or render the search result in SharePoint
2013:
Rules. These define when a result type is

applied.
Property Lists. A result type includes a list of

managed properties. A property must be
added to the list before it can be included in a
display template.
Rendering Template. A rendering template defines the screen layout of a result type.
Result type rules

You can create rules based on a number of operators, such as:
Equals or not equals.
Less than or greater than comparison
Logical operators
o
AND
OR
NOT
You can also create more complex rules by including multiple conditions, as well as managed properties.
Result type management
You can create new result types from the Site Collection Administration page by clicking Result Types.
This shows all the shipped result types and any customer result types that you have created.
13-32
When you create a new result type, you provide a name and then specify the conditions required for this
result type. The first condition is the result source. You select these from a list of options, such as
documents, text, items matching a content type, popular, and so on. You then set which types of content
you want to match on, such as PDF, text, SharePoint list, or SharePoint site. To create a more complex
result type, you can add more conditions.
With the conditions set, you can select an action. This defines the display template that you should use to
display the result type. Display templates are covered in the next topic.
The interface provides options for simple matching, so you can select a file name extension of .doc or
.docx for an Office Word document, or you can use managed properties, such as content types, to view
results. You can combine both of these elements so that your content typeProposaland your file
name extension.docxcombine and are rendered in a customer template that you design for proposal
documents only.
Result types can be managed at two levels: Search service application and site or web. There are a number
of result types available with SharePoint 2013. These are read-only, so you cannot change them. However,
you can use these as the starting point for your own custom result types by copying the originals and
making your own changes.
There is a hierarchy in result type matching. This hierarchy is:
Current web
Site collection site
Search service application
This means that the results presented are based on the cumulative rule types and then rendered by
priority.
Display Templates
The returned result types can be rendered in a

specific display template, which defines the
appearance of the result type on the screen or
visual layout. The template itself is just HTML. This
means that your web designers can use any HTML
editorSharePoint Designer, Dreamweaver, or
even Notepadto create the template. This
change makes it easier for organizations with a big
investment in non-SharePoint web design to
quickly create display templates for result types
without the need to train designers in SharePoint
development tools. Previously, all result type
rendering was defined in a single XSLT file, which could become unwieldy in an environment that wanted
to have numerous result types. In addition to this, XSLT expertise and tools are less common than the
HTML experience.
The display templates that are shipped with SharePoint 2013 are located in the Master Pages and Page
layouts/Display Templates/Search folder. When you create a new display template, the HTML file is saved
in the Search folder. If you look in this folder, you will see that for every HTML display templatewhether
out-of-the-box SharePoint 2013 or customthere is a JavaScript (.js) file of the same name associated
with the HTML (.html) file. These are generated automatically by SharePoint 2013.
13-33
Like with result types, display templates can be managed at the site collection level. This means that site
administrators can add new display templates to this folder. The goal here is to distribute administrative
responsibility and effort across your organization, streamlining, but maintaining management of change.
Planning and Configuring Search Navigation

In SharePoint 2013, there are two different modes
for the refiner Web Part: search results and faceted
navigation. With search results, the refinement
data works much like it did with SharePoint Server
2010 with some enhancements. For search results,
the refinersthe navigational elements shown on
the left navigationare generated as deep
refiners rather than the shallow refiners available
in SharePoint 2010. SharePoint 2010 displayed the
top 50 results (default setting). Now all refiners are
deep refiners out of the complete, rather than top
50, results. These can be rendered through the
display templates.
Faceted navigation
Faceted navigation, which is also called faceted search, is a method of locating information based on the
facets or attributes of the date, by applying filters. The difference between a faceted navigation and a
hierarchical navigation is that the latter is a pre-defined hierarchy, so there is far less flexibility in how
navigational elements appear. This works well in a highly structured set of navigational elements, but it
lacks flexibility where there may be many attributes or facets to a single item.
In SharePoint 2013, faceted navigation uses a term set from the term store to filter the displayed data, in
much the same way that term sets can be used for document library navigation. With each term that you
select, there are managed properties that you define should be refiners with that term. To do this, you
must configure the managed property as refinable.
To use this approach, you create refiners for you managed property. For example, if you have a managed
property of Car, you may add refiners of Manufacturer and Color, so that these appear as query
navigational refiners when a user clicks on Car. The user can then select the Manufacturer or Color as their
next facet of the navigation.
Configuring faceted navigation
There are several steps to configuring your environment for faceted navigation. The steps are as follows:
1.
The managed property must be enabled as a refiner in Central Administration by the search service
administrator. There must then be a full crawl of the content source.
2.
Site collection administrators can configure refiners after they have mapped the appropriate crawled
property to the refinable managed property.
3.
The site collection administrator can then enable a term set for faceted navigation. This is completed
in the Term store management option of Site Administration.
4.
From the same page, on the Faceted Navigation tab, the site collection administrator can add
refiners to all terms in the term set or to individual terms in the term set.
Additional Reading: You can review the detailed step list for Configuring Refiners and
Faceted Navigation on TechNet at http://go.microsoft.com/fwlink/?Linkid=299771
Managing Search Engine Optimization Settings

SharePoint 2013 introduces native support for
search engine optimization (SEO), which required
custom solutions in SharePoint Server 2010 and
earlier versions of the product. This feature
primarily focuses on Web Content Management
(WCM) implementations, because it is available
only for publishing sites with the feature activated.
To streamline administration, the feature is
configured at the site collection level.
With SharePoint 2013, you can use SEO
functionality to:
Verify site ownership with search engines.
Configure canonical URLs.
Generate a site map.
Add SEO properties for managed navigation.
13-34
Particularly for popular Internet search engines, there are engine-specific webmaster tools through which
you sign up to the search engine. When you register with some search engines, such as Bing, the engine
provides a verification code that you can add to a meta tag. You can have meta tags in web pages, where
each tag has a name and a value, and they can be used for a variety of different purposes. You can copy
this into the site collections Search Engine Optimization Setting page. This includes the meta tag in the
site pages. For example, the Bing meta tag is:
<meta name="msvalidate.01" content="unique code number" />
For most search engines, the URL that represents content uniquely is called the canonical URL. This means
that you do not get duplicate indexing if two URLs reference the same content, and it provides a higher
concentration of popularity for the single URL.
SharePoint 2013 provides automatic site map generation. This is configured by activating the Search
Engine Sitemap feature at the site collection level. This registers your site collection with a timer job that
generates a site map. When an XML site map path is specified in Robots.txt, search engines use it to
further discover content on your website. The timer job updates Robots.txt with its path. It is unlikely that
you want all of the pages on a site to have the same priority for your site map; therefore, you can set
priorities from 0.0 to 1.0, where 1.0 indicates an important page. In addition, you can specify the volatility
of pages so that important pages that change frequentlyproduct or news pages, for exampleare
tagged as changing from Hourly to Never. This means that search engines can learn the properties of
your pages from your site map. You can also tag pages to be excluded from the site map if you have
pages with content that you consider to not be appropriate for an Internet search engine to reference.
Term sets can be used to determine a navigation hierarchy that displays on a page. You can set SEO
properties as terms, which renders SEO-compliant URLs.

Scenario
13-35
You have now provisioned a search service, created content sources and crawl schedules, and deployed a
Search Center site. Basic search functionality is working as expected. However, the IT team has raised
concerns that people are finding it hard to locate their content and guidance. Your task is to make search
results from the IT team easier to find. First, you will configure result sources to help people narrow their
search results and query rules to promote particular documents. You will then add a new page to the
Search Center to display the refined search results.
Objectives
Use result sources and query rules to optimize search results.
Add pages and navigation tabs to customize the search experience.

Passw0rd: Pa$$w0rd
Exercise 1: Optimizing Search Results

Scenario
In this exercise, you will perform various optimization tasks to make it easier for people to find search
results from the IT team. First, you will create a result source that solely contains search results from the IT
team's network file share. You will then create a query rule that promotes a particular document when
people use specific search terms within the new result source.
1. Configure a result source
2. Configure a query rule
Task 1: Configure a result source

Pa$$w0rd.
Open Internet Explorer and browse to http://sharepoint.contoso.com/search. If you are prompted

for credentials, log on as CONTOSO\Administrator with the password Pa$$w0rd.
In the site collection settings, create a new result source named IT Team Fileshare.
Configure the result source to only display search results from the IT File Share content source.
Task 2: Configure a query rule
In the site collection settings, locate the search query rules for the IT Team Fileshare content source.
Add a new query rule named IT Policies.
Configure the query rule to look for the following words or phrases within the query text:
o
Policy
Password
Acceptable use
Guidelines
Requisitions
Hardware
Software
13-36
Configure the query rule condition so that the rule matches when any of the following conditions are
met:
o
The entire query matches one of the words or phrases you specified.
The start of the query matches one of the words or phrases you specified.
The end of the query matches one of the words or phrases you specified.
Configure the query rule action to add the following promoted result when a query matches the rule.
Property
Value
Name
IT Policies and Procedures
URL
file://172.16.1.20/ITShare/IT Policies and Procedures.docx
Description
This document provides definitive guidance on all IT policies and

procedures at Contoso.
Results: After completing this exercise, you should have created a result source and a query rule.
Exercise 2: Customizing the Search Experience

Scenario
In this exercise, you will customize the Search Center to use the result source and the query rule you
created in the previous exercise. First, you will add a new search results page to the Search Center. On the
new page, you will configure the Search Results Web Part to display only search results from your new
result source. You will then add a search navigation tab that enables users to browse to your page to
narrow their search results.
1. Create a new search results page
2. Add a new tab to the search results
3. Verify that searches behave as expected
Task 1: Create a new search results page
Using Internet Explorer, browse to http://sharepoint.contoso.com/search. If you are prompted for

credentials, log on as CONTOSO\Administrator with the password Pa$$w0rd.
On the Settings menu, add a new search page named itresults.
On the new page, edit the Search Results Web Part to display only results from the IT Team Fileshare
result source.
Check in and publish the page.
Task 2: Add a new tab to the search results
Locate the site-level search settings for the Search Center site.
Add a search navigation link with the following properties.

Property
Value
Name
IT
URL
/search/pages/itresults.aspx
Description
Search results from the IT team
Task 3: Verify that searches behave as expected
On the Search Center home page, run a search for Request new hardware.
Under the search box, click IT.
Verify that the page displays the IT Policies and Procedures item as a promoted result.
13-37
Results: After completing this exercise, you should have created and configured a search results page and
customized the search navigation settings.
13-38
In this module, you learned about the architecture components of the SharePoint 2013 Search service.
You also learned about the configuration options for search and the management options that are now
available to search administrators and site collection administrators.
Review Question(s)
Test Your Knowledge
Question
Which of the search architecture components parses documents?
The Crawl Component
The Content Processing Component
The Analytics Component
The Index Component
The Query Processing Component
Test Your Knowledge
Question
Which of the following is a verticals page that is automatically created when you deploy
a Search Center site?
Conversation results page
Default query page
Default results page
Local People Results (System)
Local Video Results (System)
Test Your Knowledge

Question
Which of the following managed property options enables the content of a managed
property to be returned in search results?
Advanced Searchable
Queryable
Refinable
Retrievable
Searchable
13-39

14-1
Module 14
Monitoring and Maintaining a SharePoint 2013 Environment

Contents:
Module Overview
14-1
Lesson 1: Monitoring a SharePoint 2013 Environment
14-2
14-12
Lesson 2: Tuning and Optimizing a SharePoint Environment
14-16
Lesson 3: Planning and Configuring Caching
14-30
Lesson 4: Troubleshooting a SharePoint 2013 Environment
14-37
14-45
14-47
Module Overview
Careful planning and configuration alone will not guarantee an effective Microsoft SharePoint Server 2013
deployment. To keep your SharePoint 2013 deployment performing well, you need to plan and conduct
ongoing monitoring, maintenance, optimization, and troubleshooting. In this module, you will learn how
to plan and configure monitoring in a SharePoint 2013 server farm, and how to tune and optimize the
performance of your farm on an ongoing basis. You will also learn how to use a range of tools and
techniques to troubleshoot unexpected problems in your SharePoint 2013 deployments.
Objectives
Develop and implement a monitoring plan for a SharePoint 2013 environment.
Tune and optimize a SharePoint 2013 server farm on an ongoing basis.
Plan and configure caching to improve the performance of a SharePoint 2013 deployment.
Troubleshoot errors and other issues in a SharePoint 2013 deployment.
Lesson 1
Monitoring a SharePoint 2013 Environment
14-2 Monitoring and Maintaining a SharePoint 2013 Environment
Developing an effective monitoring and maintenance strategy is an essential part of planning a

SharePoint deployment. SharePoint 2013 includes a wide range of tools and capabilities that can help you
identify and resolve potential issues before they impact end users. In this lesson, you will learn how to
plan for maintenance and monitoring and how to make effective use of the monitoring capabilities in
SharePoint 2013.
Lesson Objectives
Identify the key elements of a maintenance and monitoring plan.
Describe how to incorporate quality assurance (QA) frameworks into your maintenance and
monitoring plan.
Describe the tools and capabilities for monitoring in SharePoint 2013.
Configure the SharePoint Health Analyzer.
Configure usage and health data collection.
Configure diagnostic logging.
Planning for Maintenance and Monitoring

To ensure that your SharePoint 2013 deployment
meets the ongoing business requirements of your
organization, you should create a maintenance
and monitoring plan. The goal of this plan is to
enable you to keep SharePoint 2013 running at
optimum performance and perform proactive
maintenance tasks.
Service level agreements

Many organizations issue one or more service
standards that specify required uptime,
performance levels, and recovery times. These
service level agreements (SLAs) may exist between
departments in the organization to detail the expectations that one department has of another.
Organizations also often use SLAs to detail a required level of service between the organization and its
suppliers, customers, and partners.
A well-designed maintenance and monitoring plan enables you to meet the SLAs that affect the
SharePoint 2013 environment.
Documentation
Detailed documentation simplifies monitoring and maintenance throughout the hierarchy and ensures
that the maintenance and monitoring processes that you define are repeatable. It is also easy to review
and update the details of your maintenance and monitoring plan if you document it. Documenting the
plan is especially important in large hierarchies where there can be many SharePoint 2013 administrators
and other IT teams all working to meet SLAs for the IT infrastructure. When you design your maintenance
14-3
and monitoring plan, you should review it with other IT teams, such as the teams that are responsible for
the following services:
SQL Server
Active Directory Domain Services (AD DS), or your identity management system
Forefront Unified Access Gateway (UAG) and Threat Management Gateway (TMG)
SharePoint 2013 relies on IIS, SQL Server, and AD DS to operate correctly. If UAG/TMG is deployed in your
organization, they must be also configured to allow SharePoint to operate correctly. As such, you must
ensure that your maintenance and monitoring plan incorporates any tasks that are necessary to maintain
and monitor them.
You can provide the maintenance and monitoring plan to the SharePoint 2013 administrators who are
responsible for maintenance.
Your plan should include:
Which tasks to perform.
How to perform each task.
How often to perform each task.
Who should perform each task.
Who should update and maintain the necessary documentation.
Reference Links: For a sample SLA, see Appendix B: Sample SLA at

Planning for Quality Assurance

Quality Assurance (QA) refers to a program for the
systematic monitoring and evaluation of the
various aspects of a service to ensure that you
meet agreed standards of quality. QA programs
vary, but they focus on improving and stabilizing
the service that you provide and minimizing issues
that lead to interruptions in service.
Many service management methodologies
incorporate QA processes. The following sections
describe some examples.
ITIL
The IT Infrastructure Library (ITIL) is a set of concepts and practices for the development, management,
and provision of IT services. ITIL gives detailed descriptions of a number of important IT practices and
provides comprehensive checklists, tasks, and procedures that any IT organization can tailor to its
requirements.
MOF
Microsoft Operations Framework (MOF) 4.0 delivers practical guidance for everyday IT practices and
activities. It helps you to establish and implement reliable, cost-effective IT services.
MOF covers the entire IT life cycle by integrating:
Community-generated processes for planning, delivering, operating, and managing IT.
Governance, risk, and compliance activities.
Management reviews.
Microsoft Solutions Framework (MSF) best practices.
Sample QA program
As an example, consider the QA processes that you require for the backup and recovery of your
SharePoint 2013 infrastructure. You should define the following:
SLAs. You should formalize expectations as to which data you can recover and how long it will take
you to recover it. This may vary from site to site in your SharePoint 2013 infrastructure. This
information should be part of the SLA documentation.
Backup schedule. Your maintenance and monitoring plan should include a defined schedule for
backup. You should define what you will back upsuch as content and metadataalong with
schedules for backup. Again, the backup schedule will vary, depending on the data that you must
back up.
Restore verification procedure. Your maintenance and monitoring plan should include processes for
verifying your backups. You should verify that the backup and restore process will work by testing a
selection of backups on a regular basis.
Offsite storage. Many organizations use offsite storage as an added level of protection for their data.
If you plan to use offsite storage, you should incorporate QA processes for your supplier. For example,
does the offsite storage vendor have the appropriate certification to hold your data securely?
Reference Links: For more information about ITIL, see IT Service Management ITIL at
For more information about MOF 4.0, see Microsoft Operations Framework 4.0 at
Tools and Capabilities for Monitoring in SharePoint 2013

SharePoint 2013 comes with a wide range of tools
that can help you monitor the health and usage of
your SharePoint deployment.
The SharePoint Health Analyzer

The SharePoint Health analyzer is a built-in
SharePoint component that alerts administrators
to potential performance or configuration
problems within a SharePoint server farm. The
SharePoint Health Analyzer is based around a set
of preconfigured rules in four categories:
Security. These rules check whether your

environment breaks various security guidelines; for example, if administrator accounts are used to run
application pools or the server farm account is used for other services.
Performance. These rules detect conditions that can impact the performance of the server farm; for
example, if database indices are fragmented or the paging file size is insufficient.
Configuration. These rules detect a wide range of potential configuration problems, such as whether
outbound email is not configured, patch installation is required, the distributed cache is not enabled,
Web.config files are not identical across all servers in the farm, and so on.
Availability. These rules detect conditions that may result in server or farm downtime, such as if drives
are running out of free space, the Security Token Service is not available, or one or more servers is not
responding.
Each rule is executed periodically by a timer job, either monthly, weekly, daily, hourly, or only on demand.
When an issue is detected, the Central Administration home page displays a red banner that is aimed at
drawing your attention to the problem.
As an administrator, you can:
Enable or disable specific rules.
Change the frequency with which rules are evaluated.
Execute rules on demand.
Configure alerts or workflows on rule definitions.
Configure rules to attempt to repair detected errors automatically.
You might want to disable rules that do not apply to your environment, or run rules that regularly identify
problems on a more frequent basis. Similarly, you may want to configure alerts or workflows on rules that
regularly identify issues, for example to alert a server administrator when disk space is low. Executing rules
on demand is useful when you have resolved a problem and you want to verify your solution.
Diagnostic logging
SharePoint logs a wide range of diagnostic information to the Windows event log and to the SharePoint
Unified Logging Service (ULS) trace log. SharePoint writes information to the logs when events occur.
These events are organized by category and then by subcategory. Categories reflect major platform
areasfor example, service applications and feature setssuch as Business Connectivity Services,
Document Conversions, and SharePoint Foundation. Within each category, subcategories provide a
category-specific breakdown of functionality. For example, the Document Conversions category includes
subcategories for the Launcher Service, the Load Balancer Service, and SharePoint Foundation.
SharePoint assigns a severity to every event that occurs. For the Windows event log, these severity levels
are as follows, from lowest to highest severity:
Verbose
Information
Warning
Error
Critical
For the ULS trace logs, the severity levels are as follows, from lowest to highest severity:
Verbose
Medium
High
Monitorable
Unexpected
As an administrator, you can configure the least critical events that you want to write to the Windows
event log or the ULS trace log. You can apply your least critical event criteria to every diagnostic category,
to specific categories, or to specific subcategories. This enables you to strike a balance between providing
enough information to troubleshoot problems without filling the logs with an unnecessary amount of
information. For example, if you are experiencing problems with the Visio Services application, you might
apply more verbose logging criteria to the Visio Graphics Service category to help you diagnose the
problem.
You can configure how long the SharePoint server should keep log files and how much disk space the log
files are permitted to use. You can also enable the Event Log Flood Protection feature, which prevents
SharePoint repeating events multiple times.
Note: Trace logs are stored in a series of text files in the %PROGRAMFILES%\Common
Files\Microsoft Shared\Web Server Extensions\15\LOGS folder on each SharePoint server.
Usage and health data collection
You can configure SharePoint 2013 to collect a wide range of usage and health information. This
information can provide insights into how your deployment is used, and help you to identify components
that are performing poorly or experiencing heavy load. SharePoint 2013 collects usage and health data
from a variety of sources, including event logs; performance counters; search usage data; site collection
and site usage data; and server statistics. Information is initially collected in log files in the 15\LOGS folder.
SharePoint then uses timer jobs to collect data from these log files and update the usage database. You
can configure how often these timer jobs run, according to your monitoring requirements.
Note: SharePoint creates the usage database when you first configure usage and health
data collection. By default, the database is named WSS_Logging.
You can consume information from the usage database in a variety of ways. You can view health reports
directly from the Central Administration website. These health reports provide insights into various
aspects of your deployment, such as which pages are slowest and which users are most active. You can
view usage reports as Excel workbooks on individual site collections. You can also query the usage
database to generate reports using various tools, such as SQL Server Reporting Services.
Performance counters
Performance counters are hardware-level registers or platform-level registers that track resource
consumption and other events. For example, the more widely-used performance counters include
measures of percentage processor time, available memory, and disk queue lengths. When you install
SharePoint 2013, it adds a wide range of additional performance counters to Windows Server.
You can use performance counters in various ways. You can use the Performance Monitor tool, which is
built into Windows Server, to view live performance counter data and capture traces. You can also use the
Add-SPDiagnosticsPerformanceCounter cmdlet in Windows PowerShell to add performance counters
to the SharePoint usage database, so that the performance counter data is logged automatically at
specific intervals.
Reference Links: For more information about monitoring a SharePoint 2013 environment,
see Overview of monitoring in SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299785
Using the SharePoint Health Analyzer

The SharePoint Health Analyzer is an analysis tool
that enables you to check for potential
configuration, performance, and usage problems.
SharePoint Health Analyzer runs predefined health
rules against servers in the farm. A health rule runs
a test and returns a status that tells you the
outcome of the test. If any rule fails, the status is
written to the Health Reports list in the Central
Administration website and the Windows event
log. SharePoint Health Analyzer also creates an
alert in the Health Analyzer Reports list on the
Review problems and solutions page in Central
Administration. You can click an alert to view more information about the problem and see steps to
resolve the problem. You can also open the rule that raised the alert and change its settings.
14-7
You can edit Health Analyzer Report list items, create custom views, export the list items into Microsoft
Office Excel, subscribe to the RSS feed for the list, and perform many other tasks.
Configuring health rules

Health rules are presented as configurable list items in four categories: Security, Performance,
Configuration, and Availability. Perform the following steps to view health rules:
1.
On the Central Administration website, click Monitoring.
2.
On the Monitoring page, under Health Analyzer, click Review rule definitions.
For each rule, you can configure the following fields.

Field
Value
Title
A descriptive name for the rule.
Scope
Single Server, All Servers, or Any Server
Schedule
Hourly, Daily, Weekly, Monthly, or

OnDemandOnly
Enable
Select to enable the rule, or clear to disable

the rule.
Repair Automatically
Select if you want SharePoint to attempt to

repair the error condition automatically, or
clear if you do not.
Version
A numeric version number.
Not every option is available for every rule. For example, whether a rule is able to repair automatically
depends on how the rule is created and whether it includes the necessary implementation to execute a
repair.
Note: Developers can create custom health rules by creating classes that derive from
SPHealthAnalysisRule.
Reference Links: For more information about configuring health rules, see Configure
SharePoint Health Analyzer rules in SharePoint 2013 at
Configuring health schedules
A health rule checks for specific conditions that affect performance, configuration, and security in your
SharePoint Server deployment. A health schedule defines when SharePoint should run the health rule.
Health rules are executed by various timer jobs, depending on the schedule, the affected service, and the
scope of the rule. Perform the following steps to view timer job definitions:
1.
2.
On the Monitoring page, under Timer Jobs, click Review job definitions.
The timer jobs that run health rules all begin with Health Analysis Job. You can edit the schedule
associated with each timer job. For example, you may want to configure daily timer jobs to run at times of
low demand. You can also use PowerShell to configure SharePoint timer jobs:
Use the Get-SPTimerJob cmdlet to retrieve a timer job.
Use the Set-SPTimerJob cmdlet to set the schedule for a timer job.
Use the Start-SPTimerJob cmdlet to start a specific timer job.
Reference Links: For more information about configuring health schedules, see Configure
SharePoint Health Analyzer timer jobs in SharePoint 2013 at
Logging Usage and Health Data

You can configure SharePoint 2013 to collect a
range of information about the usage and health
of your deployment. When you first configure
usage and health data collection, SharePoint
provisions a Usage and Health Data Collection
service application (named WSS_UsageApplication
by default) and a logging database (named
WSS_Logging by default). The Usage and Health
Data Collection service application initially records
events pertaining to the criteria you configure in
log files in the 15\LOGS folder. The Microsoft
SharePoint Foundation Usage Data Import timer
job then uses these log files to update the logging database on a periodic basis.
Configuring usage and health data collection
You can configure usage and health data collection using the Central Administration website or Windows
PowerShell. Perform the following steps to configure usage and health data collection in Central
Administration:
1.
2.
On the Monitoring page, under Reporting, click Configure usage and health data collection.
3.
On the Configure usage and health data collection page, under Usage Data Collection, select
Enable usage data collection.
4.
Under Event Selection, select the usage events you want to monitor.
5.
Under Health Data Collection, select Enable health data collection, and then click OK.
14-9
You can use Windows PowerShell for more fine-grained control over the information you collect and how
you collect it. For example, you can use Windows PowerShell cmdlets to specify a new logging database
or set a longer retention period for particular information, such as page request events. You can use the
following cmdlets to manage usage and health data collection:
The Set-SPUsageService cmdlet sets parameters for the usage data to be gathered, such as the log
file location and the maximum space for log files.
The Set-SPUsageDefinition cmdlet configures the retention period for the usage logs.
The Set-SPUsageApplication cmdlet configures the settings for the logging database, such as the
database server and the credentials to use.
Viewing usage data and health reports
You can consume the data collected by the Usage and Health Data Collection service application in a
variety of ways:
You can view health reports from the Monitoring section in Central Administration. By default, the
View health reports page includes a single report named Slowest Pages.
You can generate usage reports as Excel workbooks on individual site collections.
You can create your own reports by querying the logging database, for example by using SQL Server
Reporting Services.
Reference Links: For more information about viewing usage and health data, see View
data in the logging database in SharePoint 2013 at
Guidelines for Configuring Diagnostic Logging
SharePoint 2013 collects data in the diagnostic log

that can be useful for troubleshooting. The default
settings are sufficient for most situations. However,
you may want to customize the settings,
depending on the business requirements and the
life cycle of the farm. If you are deploying a new
feature or making large-scale changes to the
environment, you can change the logging level.
For example, you can change it to a more verbose
level to capture as much data as possible about
the state of the system during the changes. You
can also change it to a lower level to reduce the
size of the log and the resources that you require to log the data. You can set the level of diagnostic
logging for the event log and for the trace log. This will limit the types and amount of information that
will be written to each log.
Best practices
14-10
The SharePoint 2013 environment may require configuration of the diagnostic logging settings after
initial deployment and throughout the systems life cycle. Use the following guidelines as best practices:
Change the drive that logging writes to. By default, diagnostic logging is configured to write logs to
the drive and partition where SharePoint 2013 is installed. Diagnostic logging can use large amounts
of drive space, and writing to the logs can affect drive performance; therefore, you should configure
logging to write to a different physical drive. You should also consider the connection speed of the
drive; if verbose-level logging is configured, many entries are written to the log. Consequently, a slow
connection may result in poor log performance.
Restrict log disk space usage. SharePoint 2013 does not limit the amount of disk space that diagnostic
logging can use. You should limit the disk space that logging uses to make sure that it does not fill
the disk, especially if you configure logging to write verbose-level events. When the space that is
available to the log file is used, the oldest logs are removed and new logging data information is
recorded.
Use the Verbose setting sparingly. Verbose logging logs every action that SharePoint 2013 takes.
Verbose-level logging can quickly use drive space and affect drive and server performance. You can
use verbose-level logging to record a greater level of detail when you are making critical changes and
then reconfigure logging to record only higher-level events after you make the change.
Regularly back up logs. The diagnostic logs contain important data. Therefore, back them up regularly
to make sure that this data is preserved. SharePoint automatically deletes when you restrict log drive
space usage, or if you keep logs for only a few days. When the threshold is met, the oldest logs are
deleted first.
Enable event log flooding protection. You enable this setting to configure the system to detect
repeating events in the Windows event log. When the same event is logged repeatedly, the repeating
events are detected and suppressed until conditions return to a typical state.
Unified Logging Service

SharePoint uses the Unified Logging Service (ULS) to write content to log files. In SharePoint 2013, by
default, the ULS log is located at %PROGRAMFILES%\Common Files\Microsoft Shared\Web Server
Extensions\15\LOGS. When you plan file permissions for farm administrators, you should consider
allowing access to this folder so that the farm administrator can read the log directly.
The ULS log can be difficult to interpret in text form. You can download an open source tool named ULS
Viewer from CodePlex, and you should make the ULS Viewer available to those who must read the log.
The ULS Viewer enables users who have access to ULS log files to view the logs by using a user-friendly
interface. You can filter, sort, highlight, and append logs to help locate data that is relevant to the issue
that you are attempting to resolve. You can use this information to diagnose problems with computers
running ULS services or to monitor machines and the events that they create.
SharePoint 2013 uses correlation IDs, which are identifiers that are internally associated with every request
and are displayed with error messages. By searching the ULS log for the correlation ID, you can identify
the request that caused the error and resolve the issue.
Windows PowerShell log management
SharePoint 2013 provides a range of PowerShell cmdlets that you can use to manage ULS log files on your
SharePoint servers. The following table summarizes the most commonly-used cmdlets.
Cmdlet
Description
Set-SPDiagnosticConfig
Configures various aspects of diagnostic logging, including

the location of the log files, the maximum disk space the
log files can consume, and whether to enable event log
flood protection.
Get-SPDiagnosticConfig
Retrieves the current diagnostic logging configuration.
Get-SPLogLevel
Returns a list of the current event throttling settings, either

for a specific category or for all categories.
Set-SPLogLevel
Sets the event throttling level for the Windows event log
and the ULS trace logs, either for a specific category or for
all categories.
Clear-SPLogLevel
Resets event throttling levels to their default values, either

for a specific category or for all categories.
New-SPLogFile
Closes the current ULS log file and creates a new one. This
can be useful if you are trying to recreate a specific error
condition and you want to capture trace data in a clean file.
Merge-SPLogFile
Merges trace log entries from every server in the server

farm into a single log file on the local computer.
Reference Links: For more information about these cmdlets, see Logging and event
cmdlets in SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299788

Scenario
14-12
Contoso has produced a governance plan for the new SharePoint 2013 intranet deployment. The
governance plan covers several aspects of monitoring and maintenance. Your task is to implement these
aspects of the governance plan. First, you will configure diagnostic logging and the SharePoint Health
Analyzer, to help the IT team identify potential issues early. Next, you will configure usage analysis to help
the IT team understand how Contoso is using the SharePoint deployment, and to plan for future growth.
Objectives
Configure usage and health data collection.
Configure diagnostic logging.
Configure and monitor SharePoint Health Analyzer rules.
Use the logging database to generate usage reports.

Passw0rd: Pa$$w0rd
Exercise 1: Configuring Usage and Health Data Collection

Scenario
In this exercise, you will configure your SharePoint deployment to collect usage and health data. When
you enable usage and health data collection, SharePoint will provision a Usage and Health Data Collection
service application, start writing usage and health data to log files, and periodically use the log files to
update the logging database. Later in this lab, you will revisit the logging database and examine the data
that SharePoint has collected.
1. Configure usage and health data collection
Task 1: Configure usage and health data collection

Pa$$w0rd.
On the Central Administration website, enable usage and health data collection with the default
settings.
Results: After completing this exercise, you should have configured SharePoint to collect usage and
health data.
Exercise 2: Configuring SharePoint Diagnostic Logging

Scenario
In this exercise, you will configure SharePoint to write verbose data to the ULS trace logs. You will also
enable event log flood protection, and restrict the disk space used by the trace logs to a maximum of 10
gigabytes (GB). You will then open the most recent trace log to view how many events SharePoint logs
within just a few seconds.
1. Configure diagnostic logging
2. Review a log file
Task 1: Configure diagnostic logging
Configure diagnostic logging with the following settings:

o
For all categories, set the least critical event to report to the trace log to Verbose.
Ensure event log flood protection is enabled.
Restrict the disk space used by the trace logs to a maximum of 10 GB.
Task 2: Review a log file
Open a File Explorer window and browse to the location of the ULS trace logs.
Open the most recent log file, and observe the number of events that are logged in just a few
seconds.
Results: After completing this exercise, you should have configured the diagnostic logging settings for a
Exercise 3: Configuring Health Analyzer Rules

Scenario
In this exercise, you will review any problems reported by the SharePoint Health Analyzer. You will review
the settings for various Health Analyzer rules, and update these settings where necessary. You will then
run a Health Analyzer rule and repair any detected issues.
1. Review Health Analyzer problems
2. Configure Health Analyzer rule definitions
3. Run a Health Analyzer rule
4. Repair a detected issue
Task 1: Review Health Analyzer problems
On the Central Administration website, review the problems and solutions reported by the Health
Analyzer.
Task 2: Configure Health Analyzer rule definitions
On the Central Administration website, review the list of Health Analyzer rule definitions.
Review the four categories of rules:

o
Security
Performance
Configuration
Availability
In the Availability category, open the Some content databases are growing too large rule.
Edit the rule definition so that it runs on a daily basis.
Note: You cannot change the actions that the rule uses to perform its health analysis task.
The actions of the rule are determined by the code used to develop the rule.
Task 3: Run a Health Analyzer rule
14-14
On the Central Administration, browse to the list of Health Analyzer rule definitions.
In the Configuration category, run the One or more categories are configured with Verbose trace
logging rule.
Browse to the list of detected problems and solutions, and notice that an item named One or more
categories are configured with Verbose trace logging has been added.
Open the One or more categories are configured with Verbose trace logging item and review the
details.
Task 4: Repair a detected issue
Click Repair Automatically to correct the problem.
Rerun the rule and verify that the issue is resolved.
Browse to the diagnostic logging settings, and verify that the trace level has been reset to the default
Medium setting in all categories and subcategories.
Results: After completing this exercise, you should have configured Health Analyzer rules and repaired
any detected issues.
Exercise 4: Reviewing Usage and Health Data

Scenario
In this exercise, you will explore the data collected by the Usage and Health Data Collection service
application. You will start by using SQL Server Management Studio to explore database views in the
logging database. You will then use data from the logging database to generate a PivotTable Report in
Excel.
1. Explore the logging database
2. Create a logging report using Microsoft Excel
Task 1: Explore the logging database

Pa$$w0rd.
Open SQL Server Management Studio and connect to the local SQL Server instance.
In the Object Explorer window, locate the WSS_Logging database.
In the WSS_Logging database, explore the many different views that collate usage data.
View the data returned by the TimerJobUsage view.
Notice that the view contains data, but that the data is not in a particularly user-friendly format.
Task 2: Create a logging report using Microsoft Excel
Open Excel and create a new data connection that retrieves data from the TimerJobUsage view in
the WSS_Logging database.
Use the data from the data connection to create a PivotTable Report with the following properties:
Rows: JobTitle
Filters: MachineName, WebApplicationName
Values: Sum of Duration
Use the PivotChart to explore the timer job usage data.
Close Excel and discard your changes.
Results: After completing this exercise, you should have used data from the SharePoint logging database
to generate a PivotTable Report in Excel.
Lesson 2
Tuning and Optimizing a SharePoint Environment
14-16
The architectural planning that you conduct before you deploy SharePoint 2013 should ensure that your
initial deployment is well placed to meet the needs of the organization. However, a SharePoint
deployment is a dynamic entitydatabases grow, site collections are added, and user distributions and
behaviors change. Reviewing and optimizing the configuration of your deployment on a regular basis will
help to maintain performance at an optimal level.
Lesson Objectives
Describe the key measures used to quantify performance.
Explain the typical characteristics of each server role in a SharePoint 2013 server farm.
Describe the major software boundaries and capacity guidelines in SharePoint 2013.
Describe how to optimize storage configuration for a SharePoint 2013 server farm.
Describe how to optimize network configuration for a SharePoint 2013 server farm.
Describe how to optimize SQL Server configuration for a SharePoint 2013 server farm.
Describe the main performance counters you can use to identify bottlenecks in a SharePoint 2013
server farm.
Quantifying Performance
Typically, the performance of a web platform such
as SharePoint is quantified using four key
measures: latency, throughput, data scale, and
availability.
Latency
Latency is the time that elapses between the user
performing an action and the client receiving
and possibly displayingthe data. For example, it
is the time that elapses between the user clicking a
link and the client displaying the destination page.
Typically, latency 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 2013 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.
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
Value
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)
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 each day by each user.
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 determine the size of the SharePoint farm to cope with peak performance
requirements.
Data scale
Data scale is the body 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
14-18
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
Permissible downtime each month
99 percent (two nines)
7 hours
99.9 percent (three nines)
43 minutes
99.99 percent (four nines)
4 minutes
Additional Reading: For more information about capacity planning for SharePoint 2013,
see Capacity management and sizing overview for SharePoint Server 2013 at
Server Roles in SharePoint 2013

Typically, a SharePoint server farm consists of
servers performing specific roles. Each role places
different demands on your hardware. A solid
understanding of the responsibilities of each
server role, together with the demands that the
server role can exert on your hardware, can help
you to identify bottlenecks and optimize the
performance of your server farm.
Note: With the exception of the database
server, every server role in a SharePoint farm is
simply a server running SharePoint. The term
server role simply indicates that you can distribute various SharePoint services so that specific
servers have specific responsibilities.
Web Front End servers
Web Front End (WFE) servers form the connection point for clients that request content or services from
SharePoint. Every request from a client is directed to a WFE server, and every response to a client is sent
from a WFE server. This means that all client requests place some load on WFE servers. A WFE server is
responsible for:
Processing incoming requests through IIS.
Requesting any data from service applications and databases that is required to service the request.
Processing the data returned by service applications and databases.
Compiling responses as ASP.NET pages and sending the responses to the requestor.
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; instead, they rely heavily on processor power and memory for
performance. Some service applications, especially those relating to business intelligence (BI) functionality,
can significantly increase processor and memory load on WFE servers, even when the service applications
are running on dedicated application servers.
To improve the performance of page rendering and client access, you can add more WFE servers to the
farm and implement network load balancing and request management.
Application servers
Application servers host service applications. You can distribute service applications between the servers in
your server farm to manage load. The specific hardware demands imposed by service applications vary
both by the type of service application and by how the service application is used. However, as a general
rule, service applications do not require disk space on the application server; instead, they may impose
significant processor and memory demands. To mitigate these demands, you should:
Conduct regular monitoring of processor and memory load on application servers.
Distribute service applications between the available application servers to allocate server load evenly.
Search servers
The search service application can add significantly to the resource requirements of a SharePoint 2013
server farm. Although the components of the search service are technically the responsibility of
application servers, many large SharePoint deployments use dedicated servers to run components of the
search service. In SharePoint 2013, the search service consists of the following major components:
The index component. The search index is divided into one or more index partitions. Each partition
stores part of the search index as a set of files on disk. Index partitions can be allocated (and
replicated) across individual servers in a server farm. The index component writes index items received
from the content processing component and issues result sets to the query processing component.
The index component can place high demands on memory and disk input and output (I/O).
The query processing component. The query processing component receives search requests from a
WFE server. It processes the request and sends it to the index component, which returns a result set. It
then processes the result set and returns it to the WFE server as search results. Typically, the query
processing component places high demands on memory and processor power.
The search administration component. The search administration component manages the processes
and timer jobs that underpin the search service. In isolation, the search administration component
does not place heavy demands on hardware.
The crawl component. The crawl component browses content sources on a scheduled basis and
provided crawled content, together with any associated metadata, to the content processing
component. The crawl component places very heavy demands on the available processor power and
consumes a large amount of I/O bandwidth.
The content processing component. The content processing component receives content and
metadata from the crawl component. It transforms the crawled items into index-ready items, for
example by parsing documents and mapping crawled properties to managed properties. Typically,
the content processing component places high demands on memory and processor power.
The analytics component. The analytics processing component analyzes crawled items and how the
search service is used. It writes the results of this analysis to the analytics reporting database. The
analytics component can place high demands on memory and processor power, and it consumes
significant I/O bandwidth.
Each of these components can be allocated to one or more application servers in the server farm.
Database servers
14-20
Database servers in a SharePoint 2013 farm run SQL Server 2012 or SQL Server 2008 R2 and host a range
of SharePoint databases, including the configuration database, content databases, and service application
databases. The database server role is generally not as processor-intensive as other server roles. However,
database servers typically experience heavy memory load and heavy I/O load. When you configure or
maintain a database server, you should ensure that sufficient memory is available, that sufficient storage is
available, and that your storage media is fast enough to prevent I/O bottlenecks.
Software Boundaries and Capacity Guidelines

To keep your SharePoint 2013 deployment
performing well, you must ensure that you stay
within the software boundaries and recommended
limits for various logical architecture components.
Although software boundaries and limits will
clearly play a major role in your logical
architecture design, they are also an ongoing
maintenance and optimization issue because
SharePoint deployments grow over time. For
example, sites and site collections proliferate,
content databases grow, user adoption increases,
and servers are scaled up or scaled out.
Guidelines for web applications and IIS websites

Consider the following guidelines when you configure SharePoint web applications and IIS websites:
Do not exceed 20 web applications per server farm. To optimize web server performance, you should
aim to keep the number of web applications and IIS websites as low as possible. If you need to
provide multiple paths to your content, use host-named site collections instead of creating additional
web application zones. Any more than 20 web applications per farm is an unsupported configuration.
Do not exceed 20 managed paths per web application. Managed paths are cached on the web server,
and a large number of managed paths increases the time and resources required to process incoming
requests.
Do not exceed 10 application pools per server. This is a general guideline, because specific limitations
are governed by your server hardware. The limiting factor is usually available memory, because each
application pool can create a significant memory overhead.
Guidelines for content databases

Consider the following guidelines when you configure content databases:
Do not exceed 500 content databases per server farm. A large number of content databases will not
affect performance for end users, but it will make certain administrative operations, such as creating
site collections, very slow. You can mitigate this to some extent by using Windows PowerShell, instead
of the Central Administration website, to manage web applications that include a large number of
content databases. Any more than 500 content databases per farm is an unsupported configuration.
Do not exceed more than 200 GB per content database for general use scenarios. You can create
content databases of up to 4 terabytes in specific scenarios (for more details, see the reference at the
end of this topic), but for general use, it is recommended that you do not exceed 200 GB.
Do not exceed more than 60 million items per content database. Items can refer to documents or list
items. If you need to store more than 60 million items, you should create additional content
databases.
Do not exceed more than 5,000 site collections per content database. This is a recommended limit, and
you can include up to 10,000 site collections per content database in certain circumstances, such as
when the site collections are personal sites. Exceeding the 5,000 site collection limit will lead to longer
downtime during upgrades.
Guidelines for site collections and content

Consider the following guidelines when you manage site collections and content:
Do not exceed more than 500,000 personal site collections and 250,000 other site collections per server
farm. Any more than 500,000 personal site collections and 250,000 other site collections is an
unsupported configuration, regardless of how the site collections are distributed across web
applications and content databases.
Do not exceed more than 250,000 sites per site collection. When you create or delete sites, the
availability of the entire site collection is affected. More than 250,000 sites per site collection is
unsupported, regardless of how the site hierarchy is structured.
Do not exceed file sizes of 2 GB. The default file size limit is 50 MB, but you can increase this up to
2 GB in the web application settings. A large number of large files will affect the performance of your
farm.
Do not exceed 30,000,000 items per list. This applies to list items in lists and documents in document
libraries. Remember that list views are typically limited to 5,000 items, so you will need to design
views carefully if you create very large lists or libraries.
Guidelines for users and groups

Consider the following guidelines when you manage users and groups:
Do not allow users to belong to more than 5,000 SharePoint groups. The time taken to evaluate user
permissions increases proportionally to the number of group memberships.
Do not add more than 2 million users to a site collection. This guideline is based on manageability
instead of performance. If you have more than 1,000 users or groups in a site collection, Microsoft
recommends that you use Windows PowerShell instead of the website user interface (UI) to manage
users.
Do not add more than 5,000 users to a SharePoint group. SharePoint 2013 performs well with up to
5,000 Active Directory principals (users or groups) in each SharePoint group. As group membership
increases, it will take SharePoint longer to validate permissions.
Do not add more than 10,000 SharePoint groups to a site collection. User management operations,
such as creating groups or adding users to existing groups, will take substantially longer if you exceed
this limit.
Additional guidelines
Software boundaries, limits, and capacity guidelines for SharePoint is a large and complex area. In
addition to the core boundaries discussed here, you also need to consider boundaries and limits for
individual service applications. Microsoft provides comprehensive recommendations in this area based on
the results of performance testing. We recommend that you review the guidelines in Software boundaries
and limits for SharePoint 2013 at http://go.microsoft.com/fwlink/?Linkid=299791
Optimizing Storage Configuration

Disk storage types and redundant array of
independent disks (RAID) configuration can have a
significant impact on the performance of database
servers. There are three main types of storage that
you can use with your database servers:
14-22
Direct-attached storage (DAS). In a DAS

configuration, a storage controller without a
network interface connects the server and disk
hardware. For example, desktop computers
use DAS configurations. Typically, DAS uses
Small Computer System Interface (SCSI), Serial
Attached SCSI (SAS), or Serial ATA (SATA)
disks.
Storage area network (SAN). A SAN connects server hardware to disk hardware over a dedicated
network. This can be an Ethernet-based network or a Fibre Channelbased 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). NAS appliances are self-contained storage devices that a server or
client can access over the network, typically through traditional file-share methods. A NAS appliance
is essentially a file server with specialized hardware optimized for file sharing.
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
milliseconds.
RAID configurations
You can distribute storage across multiple disks by using RAID arrays. A RAID array appears as a single
volume to the operating system, but it can enhance the performance or reliability of data access through
striping and mirroring:
Data striping. Involves segmenting sequential data across multiple disks. This allows multiple
segments to be read or written simultaneously, which increases data throughput.
Disk mirroring. Involves replicating a logical disk over multiple physical disks. Write operations are
performed on every physical disk simultaneously. If one disk in a mirrored array fails, the operating
system can still read data from the other disks in the array. This increases availability and eases
disaster recovery.
Some RAID configurations also include parity information, either on one or more dedicated physical disks
or distributed across all the disks in the array. This parity information can enable the RAID array to recover
from disk failure and repair corrupt data in some circumstances. The following table describes the most
common RAID configurations.
RAID Level
RAID 0
Description
Striping without mirroring or parity.
Minimum two physical disks.
RAID Level
Description
Improves data throughput.
No fault tolerance.
RAID 1
Mirroring without striping or parity.

Minimum two physical disks.
Improves fault tolerance.
Improves read performance.
No improvement to write performance.
RAID 5
Striping with distributed parity.

Minimum three physical disks.
Can recover from a single disk failure.
RAID 6
Striping with double distributed parity.

Minimum four physical disks.
Can recover from a double disk failure.
RAID 10
Striping and mirroring.

Minimum four physical disks.
Improves fault tolerance.
14-23
You should select a combination of storage type and a RAID configuration that meets your requirements
for latency and throughput. 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.
Optimizing Network Configuration

Latency, throughput, and availability are all
common measures of web application
performance. The network configuration of your
SharePoint server farm can affect all of these areas.
Network infrastructure
Web servers, application servers, and database
servers in a SharePoint farm exchange vast
amounts of data. Where possible, you should
locate the servers in your server farm on a
separate, dedicated subnet or a virtual local area
network (VLAN). This helps to reduce network
congestion and bandwidth contention, thereby
reducing latency and increasing throughput.
Network load balancing
14-24
When your server farm includes more than one WFE server, you should implement some form of network
load balancing (NLB) to distribute incoming requests among the available servers. NLB solutions can
consist of software components that run on each WFE server, or dedicated hardware components that
receive all incoming requests and distribute them according to various criteria. Most NLB solutions will:
Monitor the health of web servers in a load-balancing cluster.
Route any incoming requests to the server experiencing least load.
Stop routing requests to any servers that become unresponsive.
The Windows Server platform includes an NLB feature. In Windows Server 2012 or Windows Server 2008
R2, you can create load-balancing clusters of up to 32 web servers.
Reference Links: For more information about NLB in Windows Server 2012, see Network
Load Balancing Overview at http://go.microsoft.com/fwlink/?Linkid=299792
Request Management
SharePoint 2013 includes a new service instance named Request Management that provides advanced
request routing and load balancing functionality within the server farm. Request Management is
complementary to NLB; it is not a replacement for it. The Request Management service works by
inspecting various properties of incoming HTTP requests, such as the host name, the user agent, or the
client IP address. You can configure the service to use this information in a variety of ways. For example,
you can:
Prioritize requests. For example, you might want to prioritize end user requests over search crawl
requests.
Route requests from specific clients to specific servers. For example, you might route external requests
to security-hardened WFE servers.
Route specific types of requests to specific servers. For example, you might route all search crawl traffic
to a dedicated WFE server, or route larger requests to more powerful WFE servers.
Identify and block undesirable or harmful requests. For example, you might want to block requests
from specific machine names, IP addresses, or locations.
Route requests according to health scores. The Request Management service uses health scoring to
assess the state of WFE servers, and you can route requests to servers with better health scores.
Planning and configuring the Request Management service is a complex topic, and is beyond the scope of
this course. However, you should have a broad awareness of the capabilities of the service so that you can
identify whether it may benefit your SharePoint farm deployments.
Reference Links: For more information about Request Management in SharePoint 2013,
see:
Configure Request Manager in SharePoint Server 2013 at

Request Management in SharePoint Server 2013, Part One: Feature Capability and Architecture
Overview at http://go.microsoft.com/fwlink/?Linkid=299794
Request Management in SharePoint Server 2013, Part Two: Example Scenario and Configuration Step
by Step at http://go.microsoft.com/fwlink/?Linkid=299795
Optimizing Database Configuration

When you configure a SharePoint 2013 server
farm, you can install SQL Server using default
configuration options; however, default SQL Server
configuration options will not always provide
optimal SharePoint performance.
Optimizing TempDB
All SharePoint data goes through the tempdb
database on route to the destination SharePoint
database. During a write operation, data is first
written to the tempdb database, then to the
transaction logs, and then finally to the SharePoint
database. As such, the tempdb database is often
the bottleneck on SharePoint database servers when memory is not an issue.
Consider the following guidelines for optimizing the performance of the tempdb database:
14-25
Use multiple data files for the tempdb database. As a general rule, create one file for each processor
core on the database server.
Make the data files large enough to cope with a typical workload. As a general rule, the total file size
should be 25 percent of your largest database.
Make each data file the same size.
Put the tempdb data files and transaction logs on different disks to other SharePoint databases.
Put the tempdb data files and transaction logs on a fast I/O storage device, and use disk striping if
necessary.
Set the recovery mode of the tempdb database to SIMPLE to minimize storage requirements.
Allow the data files to grow automatically, and set the file growth increment to around 10 percent of
the data file size.
Reference Links: For more information about optimizing the tempdb database, see
Optimizing tempdb performance at http://go.microsoft.com/fwlink/?Linkid=299796
Optimizing content databases
Many of the guidelines for optimizing the tempdb database can also be applied to content databases.
Consider the following guidelines for optimizing the performance of content databases:
Add multiple data files of equal size to the primary file group. As a general rule, you should have one
file for each processor core.
Pre-size the data files to prevent regular automatic growth.
Pre-size the log files to around 25 percent of the data file size.
Keep the database size to under 200 GB.
Consider using remote binary large object (BLOB) storage (RBS) if your content databases contain
many large documents or files.
Allow the data files to grow automatically, and set the file growth increment to around 10% of the
data file size.
MAXDOP
14-26
The maximum degree of parallelism (MAXDOP) option in SQL Server specifies the number of processors
that the server should use to execute a query using parallel processing. General database guidelines
suggest that you should use a high MAXDOP value if you execute relatively few concurrent queries
relative to the number of processor cores on the database server, and a low MAXDOP value if you execute
many concurrent queries. A SharePoint deployment relies on many concurrent database queries. You
should always set the MAXDOP value to 1 on every SQL Server instance in your SharePoint server farm.
Note: Unlike previous versions of SharePoint, SharePoint 2013 will not allow you to
provision databases if the MAXDOP value is set to anything other than 1.
Auto Create Statistics and Auto Update Statistics
All SQL Server databases include options named Auto Create Statistics and Auto Update Statistics.
These relate to statistics that SQL Server collects about each database, such as the number of records and
available indexes. When it receives a query, SQL Server uses these statistics to produce an execution plan
for the query.
There has long been some debate in the SharePoint community around whether these options should be
set to ON or OFF for SharePoint databases. However, the latest guidance is that in almost all cases you
should leave the default settings for each SharePoint database unchanged. The default setting will be OFF
if the SharePoint database maintains its own statistics, or ON if SQL Server needs to manage the statistics.
Identifying and Resolving Bottlenecks

A bottleneck is the term used to describe the
limiting factor on the performance of an
application, where performance is typically
measured in terms of latency and throughput.
There will always be a bottleneck of some sort on
your server farmwhen you remove one limiting
factor, something else becomes the limiting factor.
However, identifying and removing bottlenecks is
a logical and scientific approach to resolving
performance issues and improving the
performance of your SharePoint deployment.
In terms of system resources, bottlenecks occur in
four areas:
Processor utilization
Network bandwidth and network interface card (NIC) capacity
Disk and cache I/O
Memory and page file utilization
Using performance counters
Performance counters are the primary tool for identifying bottlenecks. You can monitor performance
counters in various ways. You can use Performance Monitor (Perfmon.exe) on Windows Server 2012 or
Windows Server 2008 R2 to view performance counter data in real time, or to capture traces. You can add
performance counter data to the usage database by using the Add-SPDiagnosticsPerformanceCounter
cmdlet. This captures performance data on a periodic basis where you can use it to generate reports. You
can also use performance counters in conjunction with enterprise monitoring platforms such as Systems
Center 2012 Operations Manager (SCOM).
Identifying specific bottlenecks
The following table describes some performance counters you should monitor to identify bottlenecks,
together with guidance on problematic conditions. Note that the values for potential bottleneck
conditions are guidelines only, because the values at which a counter becomes problematic will vary
between environments.
Category
Counters
Potential Bottleneck
Condition
Resolution Options
Processor
% Processor
Time
Persistently greater
than 75%
Upgrade processor
Add additional processors
Add additional servers
Disk
Average Disk
Queue Length
Gradually increasing
Upgrade to faster disks

Increase number of disks
Implement data striping
Move some data to
alternative servers
% Idle Time
Persistently less than

90%
Persistently less than

30%
Available
Mbytes
Less than 2 GB on
WFE server
Note: On a database
server, SQL Server will
reserve as much
memory as possible.
Low available
memory on a
database server does
not necessarily
indicate a problem.
Add memory
Cache Faults/sec
than 1
Add memory
% Free Space
Move some data to

alternative disks or servers
Move some data to

Memory
Remove unnecessary
services
Increase cache size

Move some data to
Category
Counters
Potential Bottleneck
Condition
Resolution Options
Pages/sec
than 10
Add memory
% Used
Greater than 50%
Add memory
% Used Peak
Greater than 75%
Add memory
Total Bytes/sec
than 40% of capacity
Upgrade NICs
Working Set
Greater than 80% of

total memory
Add memory
% Processor
Time
than 75%
Upgrade processor
Paging File
Network
Interface
Card
Investigate further
(outgoing traffic, incoming
traffic, and memory buffers)
Process (for
example
w3wp.exe or
owstimer.exe)
Add additional processors

Add additional servers
ASP.NET
Application Pool
Recycles
Several per day
Verify application pool

settings
Ensure application pools are
not set to automatically
recycle unnecessarily
Requests
Queued
Persistent large
numbers (100s)
Add WFE servers
Request Wait
Time
Persistent delays
Add WFE servers
Requests
Rejected
Greater than 0
Add WFE servers
Reference Links: For more guidance about identifying and resolving bottlenecks, see
Monitoring and maintaining SharePoint Server 2013 at
14-28
Discussion: Optimizing SharePoint Environments

Which optimizations have led to the biggest
performance improvements in SharePoint
environments you have worked on?
14-29
Lesson 3
Planning and Configuring Caching
14-30
Caching essentially means storing copies of frequently requested items in a location where they can be
retrieved more easily, or served at a lower resource cost to the server platform. In SharePoint
deployments, this typically means storing copies of content database items on disk or in memory.
SharePoint 2013 includes four distinct caching mechanisms: the remote binary large object (BLOB) cache,
the page output cache, the object cache, and the distributed cache. Each of these caching mechanisms
operates independently and serves a distinct purpose. In this lesson, you will learn how to plan, configure,
and optimize caching for your SharePoint 2013 deployments.
Lesson Objectives
Plan and configure BLOB caching.
Plan and configure page output caching.
Plan and configure object caching.
Plan and configure the Distributed Cache service.
Planning and Configuring BLOB Caching

The BLOB cache in SharePoint stores copies of
binary large object files that are used by
webpages, such as images and CSS files, on the file
system of WFE servers. This enables SharePoint to
serve these files more quickly because the WFE
server no longer needs to retrieve the file from the
database. Some SharePoint publishing features,
such as image renditions, rely on the BLOB cache
being enabled. It is disabled by default.
Enabling the SharePoint BLOB cache

Perform the following steps to enable the
SharePoint BLOB cache:
1.
On a WFE server, open the Web.config file that corresponds to your SharePoint web application.
2.
Locate the BlobCache element.
<BlobCache location="C:\BlobCache\14"
path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4
v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="false" />
3.
Change the value of the enabled attribute to true.
4.
Adjust any other attributes as required, and then save and close the file.
The BlobCache element can include the following attributes:
Location. Specifies where the cached files should be stored on the WFE server. By default, the BLOB
cache creates a folder at C:\BlobCache\14.
Path. Specifies a regular expression that determines which file types are cached. By default, this
includes all common media files types. You can add or remove file types as required.
MaxSize. Specifies how large the BLOB cache is allowed to grow, in GB.
Enabled. Specifies whether the BLOB cache is enabled.
14-31
You can also specify a max-age attribute. This specifies how long clients should cache files from the BLOB
cache in their local browser caches, in seconds. If you do not specify a max-age value, SharePoint uses a
default value of 86,400 seconds (24 hours). The max-age attribute does not affect how long items are
stored in the BLOB cache; SharePoint automatically ensures that the BLOB cache contains the latest
version of files from the content database.
When should you use the SharePoint BLOB cache?
In most web applications, enabling the SharePoint BLOB cache will improve the performance of your sites
and reduce the load on your database servers. BLOB cache settings can become problematic during site
designif designers are regularly editing images or CSS files, you may want to disable caching at least
temporarily. The BLOB cache will increase disk I/O on your WFE servers, but this is not usually a
bottleneck.
Best Practice: If your server farm consists of more than one WFE server, you must ensure
that the Web.config files on each WFE server remain synchronized. Instead of manually editing
Web.config files, a better approach is to create a coded solution that uses the
SPWebConfigModification class within a feature receiver. This enables you to apply changes to
Web.config files on every WFE server in a single operation. It also enables you to retract or
redeploy your changes with ease.
SharePoint 2013 provides a range of performance counters you can use to monitor the performance of
your BLOB cache. For more information, see Monitoring BLOB cache performance at
Planning and Configuring Page Output Caching
In normal operation, SharePoint generates

ASP.NET pages dynamically from page templates
and database content. These ASP.NET pages are
then converted into HTML and sent to the client
browser. This is a resource-intensive process. Page
output caching stores the HTML output for
particular SharePoint pages in memory, so that
SharePoint does not need to regenerate a
commonly-requested page every time. In addition,
the page output cache can also store different
versions of the same page. For example,
anonymous users and authenticated users may see
different versions of a particular page. SharePoint is able to cache both versions so requests from either
type of user can be served without regenerating the page.
Page output caching in SharePoint applies only to publishing pages. You configure page output caching
at the site collection level through the Site Settings menu. The page output caching settings are only
available if:
The SharePoint Server Publishing Infrastructure site collection-level feature is enabled.
The SharePoint Server Publishing site-level feature is enabled.
When should you use the page output cache?
14-32
Page output caching can improve the speed at which commonly-requested pages are served, and it can
reduce the resource overhead associated with generating a page from database content. However, it does
create a memory overhead on WFE servers, because cached pages are stored in memory. Generally
speaking, page output caching is more suitable for publishing sites in which many users are likely to see
the same content. There is little benefit to enabling page output caching on sites where the user
experience is heavily individualized.
Page output cache profiles
You configure page output caching through cache profiles. Cache profiles specify the criteria used to
perform caching, such as the retention period, whether items in the cache should be security trimmed,
and whether different page versions should be cached for particular parameters, HTTP headers, or query
strings. When you enable page output caching, you select the cache profile you want to use for that site
collection, site, or page layout. You can specify different cache profiles for anonymous and authenticated
users.
Perform the following steps to create a new cache profile:
1.
On the root site for your SharePoint site collection, on the Settings menu, click Site settings.
2.
On the Site Settings page, under Site Collection Administration, click Site collection cache
profiles.
3.
On the Cache Profiles page, click new item.
4.
Specify the criteria for you cache profile, and then click Save.
Reference Links: For more information about configuring cache profiles, see Improve page
rendering by configuring output caching at http://go.microsoft.com/fwlink/?Linkid=299799
Enabling page output caching
You can configure page output caching at the site collection level, the site level, or the page layout level.
The site collectionlevel settings specify default caching settings for the entire site collection. You can
then override these settings where required at the site level or the page layout level.
Perform the following steps to configure page output caching at the site collection level:
1.
On the Settings menu, click Site settings.
2.
On the Site Settings page, under Site Collection Administration, click Site collection output
cache.
3.
On the Output Cache Settings page, select Enable output cache.
4.
Under Default Page Output Cache Profile, on the Anonymous Cache Profile and Authenticated
Cache Profile drop-down lists, click the required cache profile (or click Disabled).
5.
If you want individual sites to be able to override the default cache profile, under Page Output
Cache Policy, click Publishing sites can use a different page output cache profile.
6.
If you want individual page layouts to be able to override the default cache profile, under Page
Output Cache Policy, click Page layouts can use a different page output cache profile.
7.
If you want to include caching details on the SharePoint Developer Dashboard, under Debug Cache
Information, click Enable debug cache information on pages.
8.
Click OK.
Configuring page output caching at the site level

Perform the following steps to configure page output caching at the site level:
14-33
1.
On the Site Settings page, under Site Administration, click Site output cache.
2.
On the Published Site Output Cache Settings page, under Anonymous Cache Profile, choose
whether to inherit the default site collection cache profile or select a different cache profile.
3.
On the Published Site Output Cache Settings page, under Authenticated Cache Profile, choose
whether to inherit the default site collection cache profile or select a different cache profile.
4.
Click OK.
Configuring page output caching at the page layout level

Perform the following steps to configure page output caching for individual page layouts:
1.
On the Site Settings page, under Web Designer Galleries, click Master pages and page layouts.
2.
On the Master Page Gallery page, locate the page layout you want to configure, and then on the
drop-down menu, click Edit Properties.
3.
In the Authenticated Cache Profile drop-down box, click the cache profile you want to use.
4.
In the Anonymous Cache Profile drop-down box, click the cache profile you want to use.
5.
Click Save.
SharePoint 2013 provides a range of performance counters you can use to monitor the performance of
your page output cache. For more information, see Monitoring ASP.NET output cache performance at
Minimal Download Strategy
SharePoint 2013 provides improved page download performance through the Minimal Download
Strategy. This implements a new download manager between the client and server and retrieves the data
as needed. Each control on the page uses the download manager to update its content as necessary. A
pages chrome is defined by the master page, providing elements such as overall layout, core styling, page
behavior, location and size of the content area and includes any controls that are shared across pages. The
download manager understands controls whose display defined by the current URL, Minimal Download
Strategy provides a single .aspx page, called start.aspx, and makes only the required changes to the page.
You can enable and disable Minimal Download Strategy by using the EnableMinimalDownload property
on a per SPWeb basis.
Planning and Configuring Object Caching

The object cache stores metadata about various
SharePoint objects, such as site collections, sites,
libraries, lists, documents, and list items. Creating
these objects in memory is a resource-intensive
process, so there are clear advantages to
maintaining information in a cache to avoid
recreating the object every time a page requests
navigation data or the results of a query. Site
navigation in SharePoint, together with various
Web Parts such as the Content Query Web Part,
relies on the object cache for data. Developers can
also leverage the object cache to improve query
performance in customizations.
14-34
Like the page output cache, the object cache is only available on sites where the publishing features are
enabled.
When should you use the object cache?
By default, the object cache is enabled on every site collection. You cannot disable it, and nor would you
want to, because it improves the performance of your SharePoint farm with few, if any, drawbacks.
However, you can configure various aspects of how the object cache behaves.
Configuring the object cache

You can configure the object cache on a per-site collection-basis. To do this, on the Site Settings page,
under Site Collection Administration, click Site collection object cache. You can configure various
aspects of object caching:
Object Cache Size. By default, this is set to 100 MB.
Object Cache Reset. You can use these options to flush the object cache for your site collection.
Typically, this is not needed unless the data in the cache becomes out of sync with changes you have
made.
Cross List Query Cache Changes. By default, SharePoint caches the results of cross-list queries for 60
seconds. You can change this to check the server for changes every time a cross-list query runs, or to
use cached results for a specific number of seconds. Checking the server for changes every time will
lead to more accurate results for regularly-updated lists, but it can impact performance.
Cross List Query Results Multiplier. Because of security trimming, a specific cross-list query can return
different results for different users. To ensure that all users see a valid set of results, SharePoint will
cache more results than were initially requested. By default, the cross list query results multiplier
value is set to 3. If your lists contain a large number of unique permissions, you may want to increase
this value. However, this will increase memory consumption on WFE servers.
In most cases, you should not need to change the default object cache settings. In some circumstances,
you may need to increase the size of the cache. To find out whether this is the case, monitor the Total
number of cache compactions performance counter. If this number is high, you can improve
performance by increasing the size of the cache.
Reference Links: For more information about monitoring and optimizing the object cache,
see Monitoring object cache performance at http://go.microsoft.com/fwlink/?Linkid=299800
Planning and Configuring the Distributed Cache

SharePoint 2013 includes a new caching
mechanism known as the Distributed Cache
service. Various SharePoint features depend on
this service, including micro-blogging and
newsfeeds. The Distributed Cache service also
improves the performance of various other
features, including authentication, page load,
search, OneNote client access, and security
trimming.
The Distributed Cache service is built on Windows
Server AppFabric, which is installed as part of the
prerequisites for SharePoint 2013. The service can run in two modes:
Collocated mode. In this mode, all the servers running the Distributed Cache service form a cache
cluster. The distributed cache is then a single entity that spans each cache host.
Dedicated mode. In this mode, one server runs the Distributed Cache service and no other services.
This mode is sometimes appropriate in larger server farms when use of micro-blogging and feeds is
extensive.
By default, the Distributed Cache service runs in collocated mode and the service is started on every
SharePoint server in the server farm. The SharePoint configuration process automatically allocates 10
percent of total physical memory to the service.
Changing the allocated memory
There are two circumstances when you may need to change the memory allocated to the Distributed
Cache service:
If you add physical memory to the server, the Distributed Cache service will not automatically
recalculate the 10 percent memory allocation. You should manually change the amount of memory
allocated to the service.
If you run the Distributed Cache service in dedicated mode, you should reserve 2 GB memory for
system processes and services, and assign the remaining memory to the Distributed Cache service.
Remember that no other SharePoint services should run on a dedicated Distributed Cache server.
You can use the following procedure to change the allocated memory for the Distributed Cache service:
1.
Stop the Distributed Cache service on every cache host. You can do this from the Services on server
page in the Central Administration website.
2.
Open the SharePoint 2013 Management Shell on one of the cache hosts, and run the following
command, where <CacheSize> is the desired memory allocation in MB.
Update-SPDistributedCacheSize CacheSizeInMB <CacheSize>
3.
Restart the Distributed Cache service on all cache hosts. You can do this from the Services on server
page in the Central Administration website.
Note: You only need to run the Update-SPDistributedCacheSize cmdlet once, regardless
of the number of cache hosts.
The cache size you specify in the Update-SPDistributedCacheSize cmdlet actually represents only half
the memory assigned to the Distributed Cache service. The service will use the same amount of memory
again for memory management overhead. For example, if you want to allocate 8 GB memory to the
Distributed Cache service, you should specify 4000 MB (4 GB) as the cache size in the UpdateSPDistributedCacheSize cmdlet.
Adding and removing cache hosts
In some circumstances, you may need to add or remove servers from the cache cluster. For example, if
you want to repair or upgrade a server in the server farm, you should remove it from the cache cluster,
perform your maintenance, and then add it back into the cache cluster.
To add a server to the cache cluster, run the following Windows PowerShell cmdlet on the server you
want to add.
Adding a Cache Host to a Cache Cluster

Add-SPDistributedCacheServiceInstance
14-36
When you run this cmdlet, SharePoint will first register the Distributed Cache service on the server, so that
it appears on the Services on server list in Central Administration. SharePoint will then start the service.
When you remove a server from the cache cluster, you must first perform a graceful shutdown procedure
on the server you want to remove. This graceful shutdown transfers all cached data on the server to other
servers within the cache cluster. If you remove a server from the cache cluster without first performing a
graceful shutdown, you are likely to lose data.
To shut down a Distributed Cache service instance gracefully and then remove the server from the cache
cluster, run the following Windows PowerShell cmdlets on the server you want to remove.
Removing a Cache Host from a Cache Cluster
Stop-SPDistributedCacheServiceInstance Graceful
Remove-SPDistributedCacheServiceInstance
When you remove a server from a cache cluster, SharePoint stops the Distributed Cache service instance
and de-registers the service, so that it no longer appears on the Services on server list in Central
Administration. You can add the server back in to the cache cluster at any time by running the AddSPDistributedCacheServiceInstance cmdlet.
Reference Links: For more information about the Distributed Cache service, see:
Overview of microblog features, feeds, and the Distributed Cache service in SharePoint Server 2013 at
Plan for feeds and the Distributed Cache service (SharePoint Server 2013) at
Manage the Distributed Cache service in SharePoint Server 2013 at

Lesson 4
Troubleshooting a SharePoint 2013 Environment
14-37
Even if you plan, configure, and maintain your SharePoint deployment with the utmost care, you are still
likely to encounter unexpected issues from time to time. Taking a logical and rigorous approach to
troubleshootingand knowing which tools to use in which scenarioscan help you identify and resolve
problems quickly and effectively. In this lesson, you will learn how to use a variety of tools and techniques
to test and troubleshoot a SharePoint environment.
Lesson Objectives
Describe how to use performance management modeling to establish a baseline performance.
Explain how you can use Visual Studio to conduct load tests.
Analyze diagnostic logs to isolate specific problems.
Use server-side request tracing to identify network infrastructure issues.
Use client-side request tracing to identify issues with specific requests.
Use the SharePoint Developer Dashboard to troubleshoot individual SharePoint pages.
Discussion: Troubleshooting Tools

Which tools would you use on a regular basis to
troubleshoot issues in a SharePoint environment?
Performance Management
Modeling in SharePoint 2013
Performance management modeling for
SharePoint 2013 includes five key steps:
1.
2.
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:
o
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.
14-38
3.
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).
4.
Deploy. Deploy the established solution to the production environment.
5.
Monitor and maintain. Implement monitoring of capacity and performance, identify trends and
bottlenecks, and implement maintenance activities when required.
When 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. Typically, workload
uses the label RPS (requests per second) 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.
Reference Links: For more information about performance management modeling, see
Performance testing for SharePoint Server 2013 at http://go.microsoft.com/fwlink/?Linkid=299804
Performance Testing in SharePoint 2013

You can use a variety of tools to help you conduct
performance testing against your SharePoint
servers. One of the most comprehensive loadtesting tools for SharePoint environments is
Microsoft Visual Studio 2012.
You can configure Visual Studio 2012 load testing
in two main ways:
Local load generation. In this configuration,

the client computer running Visual Studio
generates all 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.
Distributed test controller and test agents. 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 CPU cores on the load agent computers. This configuration is suitable where a
team will be performing testing.
Note: When you use the distributed test controller approach, you can optionally 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 it is recommended only for
scenarios where an individual will perform testing.
After you choose your configuration for Visual Studio, you should create a new project in Visual Studio.
The project requires configuration of two elements:
14-39
Web tests. Web tests are an instruction for the Visual Studio load test engine to retrieve a specific
webpage or URL.
Load tests. Load tests are a collection of tests to perform as a batch. Typically, load tests include 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 website, 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.
Analyzing the SharePoint Diagnostic Logs

The Windows event log and the ULS trace logs are
usually the first place to look when you encounter
a problem in your SharePoint 2013 deployment.
The Windows event log enables you to draw errors
and unexpected events to the attention of the IT
team, who will typically monitor Windows event
logs on an ongoing basis. The ULS trace logs
typically provide more comprehensive information
that enables you to investigate problems in more
detail.
As described earlier, you can configure the level of

logging to both the Windows event log and the
ULS trace logs for individual categories and subcategories. In some circumstances, you may want to
change these event throttling settings on a temporary basis to assist you with specific troubleshooting.
For example, if users are experiencing difficulties with Visio Services, you may want to increase the logging
verbosity for the Visio Graphics Service category until the issue is resolved.
Correlation IDs
SharePoint assigns a correlation ID to every request it receives. The correlation ID takes the form of a
globally unique identifier (GUID). Whenever SharePoint presents an error to an end user, it includes the
correlation ID as part of the error message. Every entry in the ULS logs also includes a correlation ID.
Searching for the correlation ID in the ULS log files is an effective way of finding all the log entries that
relate to a specific error or unexpected condition.
ULSViewer
When SharePoint writes an entry to the ULS log files, it records a number of property values for each log
entry. These include:
Timestamp. This is the date and time at which the event occurred.
Process. This is the system process in which the event occurred, for example, Owstimer.exe
(SharePoint timer jobs) or W3wp.exe (IIS).
Area. This corresponds to the top-level event category in Central Administration.
Category. This corresponds to the second-level subcategory in Central Administration.
Level. This is the severity of the event, for example, Medium, High, or Unexpected.
Message. This provides a description of the event.
Correlation. This is the correlation ID that uniquely identifies the event occurrence.
14-40
Viewing this information in text file format can be somewhat daunting and difficult to read. ULS log files
contain a great deal of information, and it can be challenging to find the detail you need in an
unformatted text file. However, there are a range of applications available that can open ULS log files in a
more user-friendly format. One such application is ULSViewer. This is an unsupported application, made
available by Microsoft, which enables you to view ULS log files interactively. For example, ULSViewer
enables you to:
View data in a tabular format.
Highlight important data and hide unimportant data.
Filter and sort by severity, correlation ID, category, or any other properties.
Create alerts that prompt you when particular events occur.
Using tools such as ULSViewer can make troubleshooting issues using the ULS logs a faster and easier
process.
Reference Links: You can download ULSViewer from
http://go.microsoft.com/fwlink/?Linkid=299805 Please be aware that this is an unsupported
application and you use the tool at your own risk.
Using Windows PowerShell to retrieve log data
If you have some idea of what you are looking for, the Get-SPLogEvent Windows PowerShell cmdlet can
provide a powerful and flexible way of retrieving data from the ULS logs. The following table provides
some examples of how you can use the Get-SPLogEvent cmdlet.
Task
PowerShell Cmdlet
Retrieve every event that

happened in the last five minutes
Get-SPLogEvent StartTime (Get-Date).AddMinutes(-5)
Retrieve every event that

happened within a specific time
window
Get-SPLogEvent StartTime (Get-Date).AddMinutes(-10)

EndTime (Get-Date).AddMinutes(-5)
Retrieve every category that has

generated an event of severity
Warning or above
Get-SPLogEvent MinimumLevel Warning | Select Category

Unique
Retrieve the message for every

event of minimum severity
Warning that occurred in the
Timer category
Get-SPLogEvent MinimumLevel Warning | ?{$_.Category

eq "Timer"} | Select Message
Server-Side Request Tracing

In some cases, problems can occur before requests
reach SharePoint. To investigate such problems,
you may need to capture and analyze network
traffic or IIS requests.
Microsoft Message Analyzer

Microsoft Message Analyzer is the successor to
Microsoft Network Monitor (Netmon.exe).
Message Analyzer is a downloadable tool that you
can use for various network tracing tasks. For
example, you can:
Analyze the requests received by a WFE

server.
Analyze the network traffic between two servers, such as a WFE server and a gateway server.
14-41
Analyzing network traffic in this way can help you to resolve a range of problems. For example, network
tracing can highlight:
Issues with network connectivity.
Issues with firewalls blocking particular requests.
Issues with domain name system (DNS) resolution.
Issues with authentication.
Reference Links: For more information about Microsoft Message Analyzer, see Message
Analyzer Usage Scenario Guidance at http://go.microsoft.com/fwlink/?Linkid=299806
IIS Failed Request Tracing
Even when a network request makes it to a WFE server, there are still a wide range of conditions that
could prevent IIS from being able to parse the request and pass it to SharePoint. These conditions could
include incorrectly configured site bindings, configuration errors in the Web.config file, missing IIS
modules, authentication failures due to loopback checking, and so on. Failed request tracing in IIS enables
you to capture detailed information about requests as they move through the IIS pipeline.
IIS 7, IIS 7.5, and IIS 8.0 use a rule-based approach to failed request tracing. At a high level, you must
complete the following tasks:
1.
In IIS Manager, enable failed request tracing for the IIS website that hosts your SharePoint web
application.
2.
Configure failed request tracing rules to define the error conditions you want to log. These can
include specific HTTP status codes, requests that take longer than a specified time, and minimum
event severity levels.
3.
Specify the trace provider and the categories that you want to log. Depending on where in the
request pipeline you are experiencing areas, you might include the ASPNET, ISAPI Extension, or
WWW Server trace providers.
After you configure failed request tracing, detailed information about any requests that meet the criteria
specified by your failed request tracing rules is written to a log file. By default, these files are stored in the
%systemdrive%\inetpub\logs\FailedReqLogFiles\W3SVC1 folder.
Reference Links: For more information about failed request tracing in IIS, see
Troubleshooting Failed Requests Using Tracing in IIS 7 at
Client-Side Request Tracing

In some circumstances, it can be useful to monitor
HTTP requests and responses from a client
computer. One of the main advantages of this
approach is that it enables you to view all the
HTTP traffic generated by a specific page request.
This can help you to diagnose a range of
problems, such as:
Slow load times on specific webpages.
Partial request failures, such as images not

displaying.
Unexpected caching behaviors.
Issues downloading resources from content delivery networks (CDNs).
14-42
There are a range of tools that you can use to perform this kind of client-side request tracing. For
example, Fiddler is a popular freeware tool that provides a range of request monitoring and debugging
functionality. For simple request tracing, you can use the F12 Developer Tools that are built into Internet
Explorer. In Internet Explorer 9 and Internet Explorer 10, F12 Developer Tools includes a Network tab that
enables you to capture all the HTTP traffic you generate from the browser window.
If you start a request tracing session and then browse to a webpageon a SharePoint site or on any other
websiteyou may be surprised by the amount of traffic your single page request generates. A single
request to a webpage will typically result in many more requests for images, JavaScript files, CSS files,
possibly together with calls to services or advertising content. All client-side tracing tools will provide a
detailed breakdown of these requests, with timings, response codes, and various other details for each
request. This breakdown can help you to isolate the causes of slow page load times and other page load
issues.
Using the Developer Dashboard

Capturing and analyzing network traffic can help
you diagnose a range of problems, but it does not
provide any insight into how SharePoint generates
and renders specific pages. To investigate more
complex issues, you can use the SharePoint
Developer Dashboard to provide detailed insights
into the page build process and code execution
behind individual page requests.
The Developer Dashboard was introduced in
SharePoint 2010, but it has been completely
redesigned for SharePoint 2013. It now runs in a
separate window so that it does not interfere with
the page itself. It uses a dedicated Windows Communication Foundation (WCF) service,
Diagnosticsdata.svc, to retrieve results. At the top level, the Developer Dashboard provides a breakdown
of individual requests in a similar way to client-side tracing tools. For each of these individual requests,
you can view the following additional information:
Server info. This tab displays general information about the request, such as the start time, duration,
CPU time, memory, and correlation ID associated with the request.
Scopes. This tab provides a breakdown of how long the request spends at each point in the call stack.
SQL. This tab provides details of any database calls made during the processing of the request.
SPRequests. This tab provides details of any background requests that occurred in addition to the
page request.
Asserts. This tab identifies any assert calls made during the request. Assert calls are used by
developers to write details of unexpected conditions to an output window.
Service Calls. This tab provides details of any calls to web services made during the request.
ULS. This tab contains all the trace log entries associated with the current request.
Cache Calls. This tab provides details of any cache calls made during the request.
Enabling and disabling the Developer Dashboard
To make the Developer Dashboard available, open the SharePoint 2013 Management Shell and run the
following commands.
Enabling the Developer Dashboard
$content = ([Microsoft.SharePoint.Administration.SPWebService]::ContentService)
$appsetting = $content.DeveloperDashboardSettings
$appsetting.DisplayLevel =
[Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On
$appsetting.Update()
After you enable the Developer Dashboard, SharePoint adds an icon to the upper-right corner of every
page. You can launch the Developer Dashboard by clicking the icon.
14-44
To disable the Developer Dashboard, open the SharePoint 2013 Management Shell and run the following
commands.
Disabling the Developer Dashboard
[Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::Off

Scenario
Contoso users have reported slow load times for certain pages on the new SharePoint 2013 intranet
deployment. Your task is to investigate and identify any issues that could cause unnecessarily slow page
load times. First, you will capture and analyze the network traffic generated by SharePoint page requests.
Next, you will use the SharePoint Developer Dashboard to identify any issues on specific SharePoint
pages.
Objectives
Review the network traffic generated by a SharePoint page request.
Analyze the performance of individual SharePoint pages.

Passw0rd: Pa$$w0rd
Exercise 1: Analyzing Network Traffic

Scenario
In this lesson, you will use Internet Explorer F12 Developer Tools to monitor client-side network traffic.
You will browse to a SharePoint page and review the web traffic generated by the page request.
1. Configure network traffic capture
2. Review the network traffic generated by a page request
Task 1: Configure network traffic capture
Open Internet Explorer and launch F12 Developer Tools.
In F12 Developer Tools, start capturing network traffic.
Task 2: Review the network traffic generated by a page request
While F12 Developer Tools is capturing network traffic, browse to sharepoint.contoso.com.
After the page finishes loading, stop capturing network traffic.
Review the list of HTTP requests generated by the page loading process.
Notice that images, CSS files, and JavaScript files are downloaded as individual resources, and that
you can view the download time for each resource.
Select a request and switch to the detailed view.
Notice that you can review the request details, the response details, and detailed timing information.
Close F12 Developer Tools, and then close Internet Explorer.
Results: After completing this exercise, you should have captured and analyzed the network traffic
generated by a SharePoint page request.
Exercise 2: Analyzing SharePoint Page Performance

Scenario
14-46
In this exercise, you will use the SharePoint Developer Dashboard to analyze the page load process when
you request a SharePoint page. You will review page load statistics, database calls, ULS logs, and various
other aspects associated with the page request.
1. Enable the SharePoint Developer Dashboard
2. Review SharePoint page load data
Task 1: Enable the SharePoint Developer Dashboard
Use the SharePoint 2013 Management Shell to enable the SharePoint developer dashboard.
Task 2: Review SharePoint page load data
Open Internet Explorer and browse to sharepoint.contoso.com.
Launch the developer dashboard, and then switch back to the original browser window and reload
the page.
After the page finishes loading, switch back to the Developer Dashboard window.
On the Requests tab, click Request (GET:http://sharepoint.contoso.com:80/SitePages/Home.aspx).
On the Server Info tab, review the general information associated with the request.
On the SQL tab, review the database calls associated with the request.
Review the information on the remaining tabs.
Results: After completing this exercise, you should have enabled the SharePoint Developer Dashboard
and reviewed SharePoint page load data.

In this module, you learned about how to monitor and maintain a SharePoint 2013 environment.
Review Question(s)
Test Your Knowledge
Question
Which monitoring tool or capability uses rules to detect potential configuration issues?
The SharePoint Health Analyzer
Diagnostic Logging
Usage and Health Data Collection
Performance Counters
ULS Viewer
Test Your Knowledge
Question
Which RAID configuration provides both data striping and disk mirroring?
RAID 0
RAID 1
RAID 5
RAID 6
RAID 10
Test Your Knowledge

Question
Which SharePoint caching mechanism stores copies of media assets on disk?
The BLOB cache.
The page output cache.
The object cache.
The distributed cache.
The view state cache.
Test Your Knowledge
Question
When you browse to your SharePoint 2013 intranet, you see an HTTP 500 Internal
Server Error message. Which diagnostic tool might help you to investigate this
problem?
Microsoft Message Analyzer
Microsoft Network Monitor
IIS Failed Request Tracing
Internet Explorer F12 Developer Tools
The SharePoint Developer Dashboard
14-48
Course Evaluation
14-49
Your evaluation of this course will help Microsoft understand the quality of your learning experience.
Please work with your training provider to access the course evaluation form.
Microsoft will keep your answers to this survey private and confidential and will use your responses to
improve your future learning experience. Your open and honest feedback is valuable and appreciated.

L2-1
Module 2: Designing an Information Architecture
Lab A: Creating an Information Architecture

Part One
Exercise 1: Identifying Site Columns and Content Types
1.
2.
3.
4.
In the E:\Mod02\Starter folder, read the business requirements and interview transcripts in
Information Architecture 1 - Contoso Requirements.docx file.
Task 2: Complete the Content Types sheet in the Information Architecture Planning
worksheet
1.
In the E:\Mod02\Starter folder, complete the Content Types worksheet in the Information
Architecture Planning worksheet.xlsx file, replacing the ?? with valid options, based on the
business requirements.
Note: In the Site Columns list, you should identify requirements from the requirements
documentation.
In the Content Type column, you should use the drop-down list to select an appropriate option,
based on the requirements documentation.
In the Comment column, you should add any options or calculations that should be used to
populate the content types you have selected, based on the requirements documentation
Do not complete the Taxonomy sheet, because you will do this in a later exercise.
Results: Design of the site columns, content types, and term sets necessary to satisfy the business
requirements.
Lab B: Creating an Information Architecture

Part Two
Exercise 1: Designing a Business Taxonomy
1.
Navigate to the E:\Mod02\Starter folder.
2.
Launch and read the information and interview transcripts in the Information Architecture 2 Contoso Requirements.docx file.
Task 2: Identify the business taxonomy from the requirements document and
interview transcripts.
1.
Launch and complete the table in the Taxonomy worksheet of the file Information Architecture
Planning worksheet.xlsx.
Results: The design for a business taxonomy.
L2-2

L3-1
Module 3: Designing a Logical Architecture

Exercise 1: Plan a Logical Architecture
1.
2.
Log on to the 20331B-NYC-CL machine as admin with password Pa$$w0rd.
3.
4.
In the E:\Mod03\Starter folder, read the specification information in the SharePoint 2013 Logical
Architecture Requirements.docx file.
Task 2: Complete the logical architecture planning worksheet

1.
In the E:\Mod03\Starter folder, open and complete the worksheet in the SharePoint 2013 Logical
Architecture Planning Worksheet.xlsx file.
Results: This exercise will produce a completed Logical Architecture Planning Worksheet.
Exercise 2: Produce a Logical Architecture Diagram

Task 1: Complete the logical architecture diagram
1.
In the E:\Mod03\Starter folder, open and complete the diagram in the SharePoint 2013 Logical
Results: This exercise will produce a diagrammatic version of the logical architecture documentation.

L4-1
Module 4: Designing a Physical Architecture

Exercise 1: Designing a Physical Architecture
Task 1: Develop a Physical Architecture Design Document
1.
2.
3.
4.
In the E:\Mod04\Starter folder, open Contoso Physical Architecture Requirements.docx file. Read
the business requirements.
5.
Open SharePoint 2013 Logical Architecture Planning Worksheet_Solution.xlsx and SharePoint

2013 Logical Architecture Diagram.vsd to review the proposed logical architecture.
6.
Open SharePoint 2013 Physical Architecture Planning Worksheet.xlsx, and then complete the
blank cells in the Servers worksheet.
Results: After completing this exercise, you will have a complete SharePoint 2013 Physical Architecture
Planning worksheet.
Exercise 2: Develop a Physical Architecture Design Diagram

Task 1: Develop a Physical Architecture Design Diagram
1.
2.
Open your completed SharePoint 2013 Physical Architecture Planning Worksheet.xlsx file.
3.
In the E:\Mod04\Starter folder, open SharePoint 2013 Physical Architecture Diagram.vsd, and
then complete the blank areas in the diagram.
Results: After completing this exercise, you will have a complete Physical Architecture Design diagram.

L5-1
Module 5: Installing and Configuring SharePoint Server 2013
Lab A: Deploying and Configuring

SharePoint Server 2013 Part One
Exercise 1: Provisioning a SharePoint 2013 Server Farm
Task 1: Create a Server Farm Account in Active Directory
1.
2.
3.
4.
Start the 20331B-NYC-OWA-05 virtual machine. Wait for the virtual machine to display the logon
5.
Log on to the 20331B-NYC-DC-05 virtual machine as CONTOSO\Administrator with the password

Pa$$w0rd.
6.
On the Start screen, type Active Directory Administrative Center, and then press Enter.
7.
In Active Directory Administrative Center, click Contoso (local).
8.
In the Tasks pane, under Builtin, click New, and then click User.
9.
In the Create User dialog box, in the Full name box, type SharePoint Farm.
10. In the User UPN logon box, type SPFarm.

11. Verify that the User SamAccountName logon boxes have automatically populated with the
corresponding user name.
12. In the Password box, type Pa$$w0rd, and then in the Confirm password box, type Pa$$w0rd
1.
Click Other password options, select Password never expires, select User cannot change
password, and then click OK.
Task 2: Enable TCP/IP Connectivity in SQL Server

1.
Log on to the 20331B-NYC-DB-05 virtual machine as CONTOSO\Administrator with the password

Pa$$w0rd.
2.
On the Start screen, type SQL Server Configuration Manager, and then press Enter.
3.
In SQL Server Configuration Manager, expand SQL Server Network Configuration, and then click
Protocols for MSSQLSERVER.
4.
Right-click TCP/IP, and then click Enable.
5.
In the Warning dialog, click OK.
6.
Click SQL Server Services.
7.
Right-click SQL Server (MSSQLSERVER), and then click Restart.
8.
Wait for the service to restart, and then close Sql Server Configuration Manager.
Task 3: Create a SQL Server Alias on the SharePoint 2013 Server
L5-2
1.

Pa$$w0rd.
2.
On the desktop, click File Explorer, browse to C:\Windows\System32, and then double-click
cliconfg.exe.
3.
In SQL Server Client Network Utility, on the Alias tab, click Add.
4.
In the Server alias box, type ContosoDB, under Network libraries, click TCP/IP, in the Server name
box, type NYC-DB1, and then click OK.
5.
In the SQL Server Client Network Utility, click OK.
6.
In File Explorer, browse to C:\Windows\SysWOW64, and then double-click cliconfg.exe.
7.
In SQL Server Client Network Utility, on the Alias tab, click Add.
8.
In the Server alias box, type ContosoDB, under Network libraries, click TCP/IP, in the Server name
box, type NYC-DB1, and then click OK.
9.
In the SQL Server Client Network Utility, click OK.
Task 4: Run the SharePoint Products Configuration Wizard

1.
On the 20331B-NYC-SP-05 virtual machine, on the Start screen, type SharePoint Products
Configuration, and then press Enter.
2.
In the SharePoint Products Configuration Wizard, on the Welcome to SharePoint Products page,
click Next.
3.
In the SharePoint Products Configuration Wizard dialog box that warns you about services being
started or reset, click Yes.
4.
On the Connect to a server farm page, click Create a new server farm, and then click Next.
5.
On the Specify Configuration Database Settings page, in the Database server box, type
ContosoDB, in the Username box, type CONTOSO\SPFarm, in the Password box, type Pa$$w0rd,
and then click Next.
6.
On the Specify Farm Security Settings page, in the Passphrase box, type Pa$$w0rd, in the
Confirm passphrase box, type Pa$$w0rd, and then click Next.
7.
On the Configure SharePoint Central Administration Web Application page, select Specify port
number, in the Specify port number box, type 50000, and then click Next.
8.
On the Completing the SharePoint Products Configuration Wizard page, verify the settings, and
then click Next.
9.
On the Configuration Successful page, click Finish.
10. In Internet Explorer, if you are prompted to set up Internet Explorer 10, click Use recommended
security and compatibility settings, and then click OK.
11. In the Help Make SharePoint Better dialog box, click Yes, I am willing to participate
(Recommended), and then click OK.
12. On the Welcome page, click No, I will configure everything myself.
13. Close all open windows.

L5-3
Lab B: Deploying and Configuring

SharePoint Server 2013 Part Two
Exercise 1: Configuring Incoming Email
Task 1: Enable the SMTP Server feature on the SharePoint Server
1.
2.
On the Desktop, click Server Manager.
3.
In Server Manager, click Manage, and then click Add Roles and Features.
4.
In the Add Roles and Features Wizard, on the Before you begin page, click Next.
5.
On the Select installation type page, click Next.
6.
On the Select destination server page, click Next.
7.
On the Select server roles page, click Next.
8.
On the Select features page, in the Features list, click SMTP Server.
9.
In the Add features that are required for SMTP Server dialog box, make sure Include
management tools (if applicable) is selected, and then click Add Features.
10. On the Select Features page, click Next.

11. On the Confirm installation selections page, click Install.
12. Wait for the installation to complete, and then click Close.
Task 2: Configure the SMTP service

1.
On the Start screen, type IIS 6.0, and then press Enter.
2.
In Internet Information Services (IIS) 6.0 Manager, expand NYC-SP1.
3.
Right-click [SMTP Virtual Server #1], and then click Properties.
4.
In the properties window, on the Access tab, click Authentication.
5.
In the Authentication dialog box, make sure Anonymous access is selected, and then click OK.
6.
In the properties window, click Relay.
7.
In the Relay Restrictions dialog box, make sure Only the list below is selected, and then click Add.
8.
In the Computer dialog box, under Single computer, in the IP address box, type 172.16.1.21, and
then click OK three times.
9.
Expand [SMTP Virtual Server #1], right-click Domains, point to New, and then click Domain.
10. In the New SMTP Domain Wizard dialog box, click Alias, and then click Next.
11. On the Domain Name page, in the Name box, type mail.contoso.com, and then click Finish.
12. Close Internet Information Services (IIS) 6.0 Manager.
13. On the Start screen, type Services, click Settings, and then press Enter.
14. In the Services (Local) list, double-click Simple Mail Transfer Protocol (SMTP).
15. In the properties window, in the Startup type list, click Automatic.
16. If the service is not currently running, click Start, wait for the service to start.
17. In the properties window, click OK.
Task 3: Create a DNS record for the email domain and SharePoint site
L5-4
1.
2.
On the Start screen, type DNS, and then press Enter.
3.
In DNS Manager, expand NYC-DC1, expand Forward Lookup Zones, right-click Contoso.com, and
then click New Host (A or AAAA).
4.
In the New Host dialog box, in the Name box, type mail, in the IP address box, type 172.16.1.21,
and then click Add Host.
5.
In the confirmation message box, click OK.
6.
In the New Host dialog box, in the Name box, type sharepoint, in the IP address box, type
172.16.1.21, and then click Add Host.
7.
In the confirmation message box, click OK, and then click Done.
8.
Close all open windows.
Task 4: Configure incoming email settings in Central Administration

1.
2.
On the Start screen, type Central Administration, and then press Enter.
3.
On the Central Administration website, click System Settings.
4.
Click Configure incoming e-mail settings.
5.
On the Incoming E-Mail Settings page, under Enable Incoming E-Mail, click Yes.
6.
Under Directory Management Service, verify that No is selected.
7.
Under Incoming E-Mail Server Display Address, in the E-Mail server display address box, type
mail.contoso.com, and then click OK.
Task 5: Create an email-enabled Announcement app

1.
Click Application Management.
2.
3.
On the Web Applications Management page, on the ribbon, click New.
4.
In the Create New Web Application dialog box, in the Host Header box, type
sharepoint.contoso.com, and then click OK.
5.
In the Application Created dialog box, click OK.
6.
7.
On the Application Management page, click Create site collections.
8.
On the Create Site Collection page, under Web Application, verify that
http://sharepoint.contoso.com is selected.
9.
Under Title and Description, in the Title box, type Configuration Test.

L5-5
10. Under Template Selection, verify that Team Site is selected.

11. Under Primary Site Collection Administrator, in the User name box, type
CONTOSO\Administrator, and then click OK.
12. On the Top-Level Site Successfully Created page, click OK.
13. On the Start screen, type regedit, and then press Enter.
14. In Registry Editor, expand HKEY_LOCAL_MACHINE, expand SYSTEM, expand CurrentControlSet,

expand Control, and then expand Lsa.
15. Under Lsa, right-click MSV1_0, point to New, and then click Multi-String Value.
16. Type BackConnectionHostNames, and then press Enter.
17. Double-click BackConnectionHostNames, in the Value data box, type sharepoint.contoso.com,

and then click OK.
18. If a Warning dialog box appears, in the Warning dialog box, click OK.
19. Close the Registry Editor.
20. On the Start screen, type command prompt, and then press Enter.
21. In the Administrator: Command Prompt command window, run the following command:
iisreset /noforce
22. Wait for IIS to stop and restart.

23. In Internet Explorer, browse to http://sharepoint.contoso.com.
24. In the Windows Security dialog box, in the User name box, type CONTOSO\Administrator, in the
Password box, type Pa$$w0rd, and then click OK.
25. On the Configuration Test site, click Settings, and then click Add an app.
26. On the Your Apps page, click Announcements.
27. In the Adding Announcements dialog box, in the Name box, type Email Announcements, and
then click Create.
28. On the Site Contents page, point to Email Announcements, click the ellipsis (), and then click
SETTINGS.
29. On the Settings page, under Communications, click Incoming e-mail settings.
30. On the Incoming E-Mail Settings page, under Incoming E-Mail, click Yes, in the E-mail address
box, type announcements, under E-Mail Security, click Accept e-mail messages from any sender,
and then click OK.
Task 6: Test incoming email functionality

1.
Use File Explorer to browse to the E:\Mod05 folder.
2.
Right-click SendEmail.ps1, and then click Run with PowerShell.
3.
In Internet Explorer, click Email Announcements. If the list does not contain any announcements,
wait a minute and refresh the page. Repeat until an announcement is added to the list.
4.
Click the New announcement list item and view the contents. Verify that the content of the
announcements indicates that the announcement was added by email.
5.
L5-6
Results: After completing this exercise, you should have configured incoming email for the SharePoint
server. You should have configured a list to receive incoming email and verified the configuration by
sending an email message to the announcements list. You should then have verified that the list contains
the new announcement emailed to the list.
Exercise 2: Configuring Outgoing Email

Task 1: Configure outgoing email settings in Central Administration
1.
On the 20331B-NYC-SP-05 machine, if you are not already logged on, log on as
2.
3.
On the Central Administration website, click System Settings.
4.
Click Configure outgoing e-mail settings.
5.
On the Outgoing E-Mail Settings page, in the Outbound SMTP server box, type 172.16.1.21, in
the From address box, type [email protected], in the Reply-to address box, type
[email protected], and then click OK.
Task 2: Subscribe to an alert on the Email Announcements list

1.
In Internet Explorer, browse to http://sharepoint.contoso.com.
2.
In the Windows Security dialog box, in the User name box, type CONTOSO\Administrator, in the
3.
On the Configuration Test site, click Email Announcements.
4.
On the Email Announcements list, on the ribbon, on the LIST tab, click Alert Me, and then click Set
alert on this list.
5.
In the Email Announcements New Alert dialog box, click OK.
Task 3: Create a new announcement

1.
Click new announcement.
2.
On the Email Announcements New Item page, in the Title box, type New Announcement, in the
Body box, type This is a new announcement, and then click Save.
Task 4: Verify that an email message was sent

1.
Click File Explorer, and then navigate to the C:\inetpub\mailroot\Drop folder, and verify that the
folder contains two files with the file name extension .eml. If the folder does not contain two files,
wait until the files appear.
2.
Based on the Date modified column, double-click the most recent .eml file, click More options, and
then click Notepad.
3.
View the contents of the file. Verify that the content from the announcement you added in the
previous task is included in the email. The text document should include the test This is a new
announcement.
4.

L5-7
Results: After completing this exercise, you should have configured SharePoint to send outgoing email.
You should have tested that outgoing email is working correctly by using an alert on an announcements
list.
Exercise 3: Configuring Integration with Office Web Apps Server 2013

Task 1: Provision a new Office Web Apps server farm
1.
Log on to the 20331B-NYC-OWA-05 virtual machine as CONTOSO\Administrator with the password

Pa$$w0rd.
2.
On the Start screen, type PowerShell, and then press Enter.
3.
In the Administrator: Windows PowerShell command window, run the following command:
New-OfficeWebAppsFarm -InternalURL http://NYC-OWA1 -AllowHttp -EditingEnabled
4.
When prompted to confirm that users of this Office Web Apps Server have the required licenses, type
Y, and then press Enter.
5.
On the Start screen, click Internet Explorer, if you are prompted to set up Internet Explorer 10, click
User recommended security and compatibility settings, and then click OK.
6.
In Internet Explorer, browse to http://NYC-OWA1/hosting/discovery, and then verify that the XML
description for the discovery service appears.
Task 2: Configure the SharePoint server farm to use the Office Web Apps server farm
1.
2.
On the Start screen, type SharePoint Management Shell, and then press Enter.
3.
In the Administrator: SharePoint 2013 Management Shell command window, run the following
command:
New-SPWOPIBinding -ServerName NYC-OWA1 -AllowHTTP
4.
In the command window, run the following command:

Set-SPWOPIZone -Zone "internal-http"
5.
In the command window, run the following commands:

$config = Get-SPSecurityTokenServiceConfig
$config.AllowOAuthOverHttp = $true
$config.Update()
Task 3: Verify that Office Web Apps integration is configured correctly

1.
On the Start screen, click Internet Explorer.
2.
3.
In the Windows Security dialog box, in the User name box, type CONTOSO\Administrator, in the
4.
On the Configuration Test site, click Documents.
5.
Click new document, and then click Excel workbook.
6.
In the Create a new document dialog box, in the Document Name box, type OWA Integration
Test, and then click OK.
7.
Verify that the workbook opens in the Microsoft Excel Web App.
8.
Close all open documents.
L5-8
Results: After completing this exercise, you should have configured integration between Office Web Apps
Server 2013 and SharePoint 2013. You should have tested this integration by creating a new Excel
workbook and viewing the workbook in the Excel Web App.

L6-1
Module 6: Creating Web Applications and Site Collections
Lab A: Creating and Configuring Web

Applications
Exercise 1: Creating a Web Application
Task 1: Configure DNS for the new web applications
1.
2.
3.
4.
Log on to the 20331B-NYC-DC-06 machine as [email protected] with the password

Pa$$w0rd.
5.
6.
In DNS Manager, expand Forward Lookup Zones, right-click Contoso.com, and then click New
Host (A or AAAA).
7.
In the New Host dialog box, in the Name box, type sales, in the IP address box, type 172.16.1.40,
8.
In the DNS dialog box, click OK.
9.
In the New Host dialog box, in the Name box, type finance, in the IP address box, type
10. In the DNS dialog box, click OK.

11. In the New Host dialog box, click Done.
12. Right-click Forward Lookup Zones, and then click New Zone.
13. In the New Zone Wizard dialog box, on the Welcome to the New Zone Wizard page, click Next.
14. On the Zone Type page, click Next.
15. On the Active Directory Zone Replication Scope page, click Next.
16. On the Zone Name page, in the Zone name box, type sales, and then click Next.
17. On the Dynamic Update page, click Next.
18. On the Completing the New Zone Wizard page, click Finish.
19. Right-click sales, and then click New Host (A or AAAA).
20. In the New Host dialog box, in the IP address box, type 172.16.1.40, and then click Add Host.
23. Right-click Forward Lookup Zones, and then click New Zone.
24. In the New Zone Wizard dialog box, on the Welcome to the New Zone Wizard page, click Next.
25. On the Zone Type page, click Next.

26. On the Active Directory Zone Replication Scope page, click Next.
27. On the Zone Name page, in the Zone name box, type finance, and then click Next.
28. On the Dynamic Update page, click Next.
29. On the Completing the New Zone Wizard page, click Finish.
30. Right-click finance, and then click New Host (A or AAAA).
31. In the New Host dialog box, in the IP address box, type 172.16.1.41, and then click Add Host.
Task 2: Create service accounts for the web applications
L6-2
1.
2.
3.
4.
In the Create User dialog box, in the Full name box, type Sales Web App Service Account.
5.
In the User UPN logon box, type SPSalesWebApp, verify that the User SamAccountName logon
boxes have automatically populated with the corresponding user name.
6.
In the Password box, type Pa$$w0rd, and then in the Confirm password box, type Pa$$w0rd.
7.
Click Other password options, select the Password never expires, and User cannot change
password check boxes, and then click OK.
8.
9.
In the Create User dialog box, in the Full name box, type Finance Web App Service Account.
10. In the User UPN logon box, type SPFinanceWebApp, verify that the User SamAccountName
logon boxes have automatically populated with the corresponding user name.
11. In the Password box, type Pa$$w0rd, and then in the Confirm password box, type Pa$$w0rd.
12. Click Other password options, select the Password never expires, and User cannot change
Task 3: Assign additional IP addresses to the SharePoint Server

1.
2.
On the Start screen, type Network Connections, click Settings, and then click View network
connections.
3.
Right-click the network adapter, and then click Properties.
4.
In the Local Area Connection Properties dialog box, click Internet Protocol Version 4 (TCP/IPv4),
and then click Properties.
5.
In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, click Advanced.
6.
In the Advanced TCP/IP Settings dialog box, on the IP Settings tab, under IP addresses, click Add.
7.
In the TCP/IP address box, type 172.16.1.40, and then click Add.

L6-3
8.
In the Advanced TCP/IP Settings dialog box, on the IP Settings tab, under IP addresses, click Add.
9.
In the TCP/IP address box, type 172.16.1.41, and then click Add.
10. In the Advanced TCP/IP Settings dialog box, click OK.

11. In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, click OK.
12. In the Local Area Connection Properties dialog box, click Close.
Task 4: Register the new service accounts as SharePoint managed accounts

1.
2.
In Central Administration, click Security, and then on the Security page, under General Security,
click Configure managed accounts.
3.
On the Managed Accounts page, click Register Managed Account.
4.
On the Register Managed Account page, in the User name box, type contoso\SPSalesWebApp, in
the Password box, type Pa$$w0rd, and then click OK.
5.
6.
On the Register Managed Account page, in the User name box, type
contoso\SPFinanceWebApp, in the Password box, type Pa$$w0rd, and then click OK.
Task 5: Create the web applications

1.
2.
3.
4.
In the Create New Web Application dialog box, under Create a new IIS web site, in the Name box,
type SharePointSales - 80.
5.
In the Port box, type 80.
6.
In the Host Header box, type sales.local.
7.
In the Path box, type C:\inetpub\wwwroot\wss\VirtualDirectories\Sales80.
8.
Under Application Pool, in the Application pool name box, type SharePointSales - 80.
9.
In the Configurable list, click CONTOSO\SPSalesWebApp, and then click OK.
10. In the Application Created dialog box, click OK.

11. On the Web Applications Management page, on the ribbon, click New.
12. In the Create New Web Application dialog box, in the Port box, type 80.
13. In the Host Header box, type finance.contoso.com.
14. Under Application Pool, in the Application pool name box, type SharePointFinance - 80.
15. In the Configurable list, click CONTOSO\SPFinanceWebApp, and then click OK.
16. In the Application Created dialog box, click OK.
17. On the Start screen, type IIS, and then press Enter.
18. In Internet Information Services (IIS) Manager, expand NYC-SP1 (CONTOSO\Administrator).
L6-4
19. If the Internet Information Services (IIS) Manager dialog box appears, asking you about getting
started with Microsoft Web Platform, click No.
20. Expand Sites, and then click SharePointSales - 80.
21. In the Actions pane, click Bindings.
22. In the Site Bindings dialog box, click Add.
23. In the Add Site Binding dialog box, in the IP address list, click 172.16.1.40, and then click OK.
24. In the Site Bindings dialog box, click Close.
25. In the Connections pane, click SharePoint - finance.contoso.com80.
26. In the Actions pane, click Bindings.
27. In the Site Bindings dialog box, click Add.
28. In the Add Site Binding dialog box, in the IP address list, click 172.16.1.41, and then click OK.
29. In the Site Bindings dialog box, click Close.
30. Close Internet Information Services (IIS) Manager.
Task 6: Disable loopback checking for the required domains

1.
On the Start screen, type regedit, and then press Enter.
2.
In Registry Editor, expand HKEY_LOCAL_MACHINE, expand SYSTEM, expand CurrentControlSet,

expand Control, and then expand Lsa.
3.
Under Lsa, click MSV1_0, double-click BackConnectionHostNames.
4.
In the Edit Multi-String dialog box, in the Value data box, on a new line, type sales.contoso.com,
and then press Enter.
5.
Type sales, and then press Enter.
6.
Type finance.contoso.com, and then press Enter.
7.
Type finance, and then click OK.
8.
If a Warning dialog box appears, click OK.
9.
On the Start screen, type Command Prompt, and then press Enter.
10. At the command prompt, run the following command.

iisreset /noforce
Results: After completing this exercise, you should have created new web applications on the SharePoint
server. You should have created the necessary service accounts, and configured DNS, and then configured
the SharePoint server to permit browsing custom domains on the SharePoint server.

L6-5
Exercise 2: Configuring a Web Application

Task 1: Add a new managed path to the finance.contoso.com web application
1.
On the Central Administration website, click Application Management, and then click Manage web
applications.
2.
Click SharePoint - finance.contoso.com:80, and then on the ribbon, click Managed Paths.
3.
In the Define Managed Paths dialog box, under Add a New Path, in the Path box, type country.
4.
In the Type list, ensure Wildcard inclusion is selected, click Add Path, and then click OK.
Task 2: Configure the outgoing email address for the web applications
1.
Select the finance.contoso.com:80 web application, then on the ribbon, click General Settings, and
then click Outgoing E-mail.
2.
In the Web Application Outgoing E-Mail Settings dialog box, in the From address box, type
3.
Click SharePointSales - 80, on the ribbon, click General Settings, and then click Outgoing E-mail.
4.
In the Web Application Outgoing E-Mail Settings dialog box, in the From address box, type
Results: After completing this exercise, you should have configured outgoing email settings and managed
paths for a web application.
Lab B: Creating and Configuring Site

Collections
Exercise 1: Creating Site Collections
Task 1: Use Central Administration to create a top-level site collection in the
L6-6
1.
On the Central Administration website, click Application Management.
2.
On the Application Management page, click Create site collections.
3.
http://finance.contoso.com is selected. If it is not currently selected, click the current web
application, click Change Web Application, and then click SharePoint - finance.contoso.com80.
4.
Under Title and Description, in the Title box, type Finance Extranet.
5.
Under Web Site Address, in the URL list, ensure / is selected.
6.
Under Template Selection, verify that Team Site is selected.
7.
Under Primary Site Collection Administrator, in the User name box, type
8.
On the Top-Level Site Successfully Created page, click OK.
9.
Task 2: Use Windows PowerShell to create a host named site collection in the
1.
2.
At the command prompt, run the following command.
New-SPSite http://finance -HostHeaderWebApplication http://finance.contoso.com -Name

"Finance Intranet" -OwnerAlias CONTOSO\Administrator -Template STS#0
Task 3: Use Windows PowerShell to create a host-named site collection with multiple
URLs in the sales web application.
1.

New-SPSite http://sales.contoso.com -HostHeaderWebApplication http://sales.local Name "Sales" -OwnerAlias CONTOSO\Administrator -Template STS#0
2.

Set-SPSiteUrl -Id http://sales.contoso.com -Url http://sales -Zone Intranet

1.
2.
In Internet Explorer, browse to http://finance.contoso.com.
3.
In the Windows Security dialog box, in the User name, type Administrator, and in the Password
box, type Pa$$w0rd, and then click OK.
4.
Verify that the browser displays the Finance Extranet site.

L6-7
5.
Click the New Tab button, and then browse to the http://finance site. Verify that the browser
displays the Finance Intranet site.
6.
Click the New Tab button, and then browse to the http://sales.contoso.com site.
7.
8.
Verify that the browser displays the Sales site.
9.
Click the New Tab button, and then browse to the http://sales site. Verify that the browser displays
the Sales site and that this is the same site as the http://sales.contoso.com site.
10. Close Internet Explorer.
Results: After completing this exercise, you should have created site collections by using the Central
Administration website, and created host-named site collections by using Windows PowerShell.
Exercise 2: Creating Site Collections in New Content Databases

Task 1: Use Windows PowerShell to create new content databases
1.
New-SPContentDatabase -Name WSS_Content_UK -WebApplication http://finance.contoso.com
2.
3.
New-SPContentDatabase -Name WSS_Content_USA -WebApplication http://finance.contoso.com
Task 2: Use Windows PowerShell to create new site collections

1.

New-SPSite -Url "http://finance.contoso.com/country/UK" -ContentDatabase
WSS_Content_UK -Name "UK" -OwnerAlias CONTOSO\Administrator -Template "STS#0"
2.

New-SPSite -Url "http://finance.contoso.com/country/USA" -ContentDatabase
WSS_Content_USA -Name "USA" -OwnerAlias CONTOSO\Administrator -Template "STS#0"

1.
2.
In Internet Explorer, browse to http://finance.contoso.com/country/UK.
3.
4.
Verify that the browser displays the UK site.
5.
Click the New Tab button, and then browse to the http://finance.contoso.com/country/USA site.
6.
Verify that the browser displays the USA site.
7.
L6-8
Results: After completing this exercise, you should have used Windows PowerShell to create new content
databases and new site collections that use the new content databases.
Exercise 3: Creating a Warm-up Script

Task 1: Test the response time of your SharePoint site after an application pool is
recycled
1.
2.

iisreset /noforce
3.
4.
In Internet Explorer, browse to http://finance, and time how long it takes for the site to finish
loading.
5.
6.
7.
loading. Verify that the page loads faster than the first time you visited this site.
8.
Task 2: Use Windows PowerShell to create a warm-up script for the

1.
On the Start screen, type Notepad, and then press Enter.
2.
In Notepad, on the File menu, click Save.
3.
In the Save As dialog box, in the File name box, type WarmUp.ps1, in the Save as type list, click All
Files (*.*), and then click Save.
4.
Add the following code to the file.

$wc = New-Object System.Net.WebClient
5.

$wc.Credentials = [System.Net.CredentialCache]::DefaultCredentials
6.

$wc.DownloadString("http://finance")
7.
On the File menu, click Save, and then on the File menu, click Exit.

L6-9
Task 3: Test the warm-up script.

1.
2.

iisreset /noforce
3.
4.
loading.
5.
6.

iisreset /noforce
7.
Click File Explorer, and then browse to the Documents library.
8.
In the Documents library, right-click WarmUp.ps1, and then click Run with PowerShell. Wait for
the script to complete.
9.
10. In Internet Explorer, browse to http://finance, and time how long it takes for the site to finish
loading. Verify that the page loads faster than the first time you visited this site.
Results: After completing this exercise, you should have created a warm-up script for you SharePoint
sites.

L7-1
Module 7: Planning and Configuring Service Applications
Lab: Planning and Configuring Service

Applications
1.
2.
3.
4.
Log on to the 20331B-NYC-DC-07 virtual machine as [email protected] with password

Pa$$w0rd.
5.
6.
7.
8.
In the Create User dialog box, in the Full name box, type SharePoint General MMS.
9.
In the User UPN logon box, type SPGeneralMMS, and then verify that the User SamAccountName
10. In the Password and Confirm password boxes, type Pa$$w0rd.

Task 2: Configure the State Service

1.
Log on to the 20331B-NYC-SP-07 virtual machine as [email protected] with the

password Pa$$w0rd.
2.
On the Start screen, type SharePoint 2013 Management Shell, and then press Enter.
3.
At the command prompt, type the following command, and then press Enter:
$service = New-SPStateServiceApplication -Name "Contoso State Service"
4.
New-SPStateServiceDatabase -Name "ContosoStateDB" -ServiceApplication $service
5.
New-SPStateServiceApplicationProxy -Name "Contoso State Service" -ServiceApplication

$service -DefaultProxyGroup
6.
Close the SharePoint 2013 Management Shell.
7.
Wait for ten minutes before you proceed to the next task.
L7-2
1.
2.
3.
On the Security page, under General Security, click Configure managed accounts.
4.
5.
On the Register Managed Account page, in the User name box, type contoso\SPGeneralMMS, in

1.
Click Central Administration, and then under System Settings, click Manage services on server.
2.
Locate the Managed Metadata Web Service service, and then in that row, click Start.

1.
In Internet Explorer, on a new tab, browse to http://sharepoint.contoso.com.
2.
In the Windows Security dialog box, in the User name box, type administrator, in the Password
3.
Click Settings and then click Site settings.
4.
On the Site Settings page, under Site Collection Administration, click Site collection features.
5.
On the Site Collection Features page, in the Content Type Syndication Hub row, click Activate.
6.
Refresh the page and verify that the Content Type Syndication Hub Feature now has a status of
Active.
7.
In Internet Explorer, close the current tab.
8.
On the Central Administration web site, click Application Management, and then under Service
Applications, click Manage service applications.
9.
On the ribbon, click New, and then click Managed Metadata Service.
10. In the Name box, type Contoso General Managed Metadata.

11. In the Database Name box, type ContosoGeneralMMSDB.
12. Click Create new application pool, and then in the Application pool name box, type
ContosoGeneralMMSAppPool.
13. In the Application Pool section, in the Configurable list, click CONTOSO\SPGeneralMMS.
14. In the Content Type hub box, type http://sharepoint.contoso.com, and then click OK.
Task 6: Verify that the service application was provisioned successfully and add terms
to the term store
1.
Click Contoso General Managed Metadata service.
2.
Verify that the Term Store Management Tool page displays correctly, and then verify that the
taxonomy term store contains the default term sets People, Search Dictionaries, and System.
Note: If the page renders incorrectly, or you do not see the People and Search
Dictionaries term sets, then reload the page.
3.
Expand People, click Department, click Create Term, type Marketing and then press Enter.

L7-3
4.
Type Sales, press Enter, and then click any white space.
Results: After completing this exercise, you should have enabled, provisioned, and configured a Managed
Metadata Service application by using Central Administration.

Windows PowerShell
Task 1: Create a service account to run the Managed Metadata Service instance
1.
Switch to the 20331B-NYC-DC-07 virtual machine. If you are not already logged on, log on to the
20331B-NYC-DC-07 virtual machine as [email protected] with password Pa$$w0rd.
2.
On the Start screen, type Active Directory PowerShell, and then press Enter.
3.
At the command prompt, run the following command:

New-ADUser -Name "SharePoint Sales MMS" -SamAccountName "SPSalesMMS" UserPrincipalName "[email protected]" -Type "User"
4.
At the command prompt, run the following commands:

$user = "SPSalesMMS"
$password = ConvertTo-SecureString -String "Passw0rd!" -AsPlainText -Force
Set-ADAccountPassword -Identity $user -NewPassword $password -Reset
5.

Enable-ADAccount -Identity $user
6.

Set-ADAccountControl -Identity $user -CannotChangePassword $true PasswordNeverExpires $true
7.

Set-ADUser -Identity $user -ChangePasswordAtLogon $false
8.
Close the command prompt.

1.
Switch to the 20331B-NYC-SP-07 virtual machine. If you are not already logged on, log on to the
20331B-NYC-SP-07 virtual machine as [email protected] with password Pa$$w0rd.
2.
3.

New-SPManagedAccount
4.
In the Windows PowerShell Credential dialog box, in the User name box, type
[email protected], in the Password box, type Passw0rd!, and then click OK.
5.
Get-SPManagedAccount | Select UserName
6.
Verify that the SPSalesMMS user account appears in the list of registered accounts.

1.

$AppPool = New-SPServiceApplicationPool -Name ContosoSalesMMSAppPool -Account
[email protected]
2.

$MMS = New-SPMetadataServiceApplication -Name "Contoso Sales Managed Metadata" ApplicationPool $AppPool -DatabaseName ContosoSalesMMS -HubUri
"http://sales.contoso.com"
3.

New-SPMetadataServiceApplicationProxy -Name "Contoso Sales Managed Metadata" ServiceApplication $MMS -DefaultProxyGroup
L7-4
4.
On the Start screen, type SharePoint Central Administration, and then press Enter.
5.
Under Application Management, click Manage service applications, and then verify that there are
two Managed Metadata service instances included in the list (both should also have corresponding
proxy connections).
Results: After completing this exercise, you should have enabled, provisioned, and configured a managed
metadata service application by using Windows PowerShell.
Exercise 3: Configuring Service Applications for Document Conversions

Task 1: Start the required services
1.
2.
Locate the Word Automation Services service, and then in that row, click Start.
3.
Locate the PowerPoint Conversion Service service, and then in that row, click Start.
4.
Locate the Document Conversions Load Balancer Service, and then in that row, click Start.
5.
Locate the Document Conversions Launcher Service service, and then in that row, click Start.
6.
On the Launcher Service Settings page, in the Load Balancer server list, click NYC-SP1, and then
click OK.
Task 2: Create a service account to run the Word Automation Services service
application
1.
Switch to the 20331B-NYC-DC-07 virtual machine. If you are not already logged on, log on to the
20331B-NYC-DC-07 virtual machine as [email protected] with password Pa$$w0rd.
2.

L7-5
3.
In the Administrator: Active Directory Module for Windows PowerShell command window, run
the following command:
New-ADUser -Name "SharePoint Word Automation" -SamAccountName "SPWordAutomation" UserPrincipalName "[email protected]" -Type "User"
4.

$user = "SPWordAutomation"
5.

6.

7.

8.

9.
Close the Administrator: Active Directory Module for Windows PowerShell window.

1.
2.

3.
In the Windows PowerShell Credential dialog box, in the User name box, type
[email protected], in the Password box, type Passw0rd!, and then click OK.
4.

5.
Verify that the SPWordAutomation user account appears in the list of registered accounts.
Task 4: Create a new Word Automation Services application instance

1.
$AppPool = New-SPServiceApplicationPool -Name ContosoWordAutomationAppPool -Account

[email protected]
2.
$WCS = New-SPWordConversionServiceApplication -Name "Contoso Word Automation Service"

-ApplicationPool $AppPool -DatabaseName ContosoWordAutomation
3.
4.
L7-6
Under Application Management, click Manage service applications, and then verify that the
Contoso Word Automation Service appears in the list (it should also have a corresponding proxy
connection).
Task 5: Create a service account to run the PowerPoint Conversion Services service
application
1.
Switch to the 20331B-NYC-DC-07 virtual machine.
2.
3.

New-ADUser -Name "SharePoint PowerPoint Conversion" -SamAccountName
"SPPowerPointConv" -UserPrincipalName "[email protected]" -Type "User"
4.

$user = "SPPowerPointConv"
5.

6.

7.

8.
Close the Administrator: Active Directory Module for Windows PowerShell window.

1.
2.
3.

4.
In the authentication prompt, in the User name box, type [email protected], in the
Password box, type Passw0rd!, and then click OK.
5.

6.
Verify that the SPPowerPointConv user account appears in the list of registered accounts.
Task 7: Create a new PowerPoint Conversion Services application instance

1.

$AppPool = New-SPServiceApplicationPool -Name ContosoPowerPointConvAppPool -Account
[email protected]

L7-7
2.

$PPT = New-SPPowerPointConversionServiceApplication -Name "Contoso PowerPoint
Conversion" -ApplicationPool $AppPool
3.

New-SPPowerPointConversionServiceApplicationProxy -Name "Contoso PowerPoint
Conversion Proxy" -ServiceApplication $PPT
4.
5.
Under Application Management, click Manage service applications, and then verify that the
Contoso PowerPoint Conversion service appears in the list (it should also have a corresponding
proxy connection).
Task 8: Enable document conversions on the sharepoint.contoso.com and

sales.contoso.com web applications
1.
Click Central Administration, click General Application Settings.
2.
On the General Application Settings page, under External Service Connections, click Configure
document conversions.
3.
On the Configure Document Conversions page, verify that the Web Application specifies
http://sharepoint.contoso.com; if it does not, click the address, click Change Web Application, and
then in the Select Web Application dialog box, click SharePoint - sharepoint.contoso.com80.
4.
Under Enable document conversions for this site?, click Yes.
5.
In the Load Balancer server list, click NYC-SP1, and then click Apply.
6.
Under Web Application, click http://sharepoint.contoso.com, click Change Web Application.
7.
In the Select Web Application dialog box, click SharePointSales - 80.
8.
Under Enable document conversions for this site?, click Yes.
9.
In the Load Balancer server list, click NYC-SP1, and then click OK.
Results: After completing this exercise, you should have provisioned document conversion service
applications by using Windows PowerShell and configured those services by using the SharePoint 2013
Central Administration website.
Exercise 4: Configuring Service Application Proxy Groups

Task 1: Create a new service application proxy group named General
1.
2.

$proxyGroup = New-SPServiceApplicationProxyGroup "General"
3.

Get-SPServiceApplicationProxy | select DisplayName
4.
View the results; verify that the service application proxies that you created in the previous tasks
appear in the list.
5.

$proxy = Get-SPServiceApplicationProxy | where {$_.DisplayName -like "Contoso
General*"}
Add-SPServiceApplicationProxyGroupMember $proxyGroup -Member $proxy
6.
L7-8
$proxy = Get-SPServiceApplicationProxy | where {$_.DisplayName -like "Contoso Word*"}

7.

PowerPoint*"}
Task 2: Create a new service application proxy group named Sales

1.

$proxyGroup = New-SPServiceApplicationProxyGroup "Sales"
2.

Sales*"}
3.
$proxy = Get-SPServiceApplicationProxy | where {$_.DisplayName -like "Contoso Word*"}

4.

PowerPoint*"}
5.
Task 3: Map proxy groups to web applications

1.
2.
3.
Under Service Applications, click Configure service application associations.
4.
Click SharePoint - sharepoint.contoso.com80.
5.
In the Configure Service Application Associations dialog box, in the Edit the following group of
connections list, click General, and then click OK.
6.
Click SharePointSales - 80.
7.
In the Configure Service Application Associations dialog box, in the Edit the following group of
connections list, click Sales, and then click OK.

L7-9
Task 4: Verify managed metadata term set associations

1.
In Internet Explorer, navigate to http://sharepoint.contoso.com.
2.
3.
Click the Settings button, and then click Site settings.
4.
On the Site Settings page, under Web Designer Galleries, click Site columns, and then click
Create.
5.
Under Name and Type, click Managed Metadata.
6.
After the page refreshes, under Term Set Settings, verify that Contoso General Managed
Metadata is included as the root node.
7.
In Internet Explorer, navigate to http://sales.contoso.com.
8.
9.
10. On the Site Settings page, under Web Designer Galleries, click Site columns, and then click
Create.
11. Under Name and Type, click Managed Metadata.
12. After the page refreshes, under Term Set Settings, verify that Contoso Sales Managed Metadata is
included as the root node.
Task 5: Verify document conversion configuration

1.
2.
Under Site Collection Administration, click Site collection features.
3.
Locate the SharePoint Server Publishing Infrastructure site collection feature, and then in that row,
click Activate.
4.
Click Site Settings to return to the Site Settings page.
5.
Under Site Actions, click Manage site features.
6.
Locate the SharePoint Server Publishing site feature, and then in that row, click Activate.
7.
In the current navigation (on the left of the page), click Documents.
8.
Locate the ConversionTest document, and in that row, click the ellipsis ().
9.
On the pop-up dialog box, click the ellipsis (), point to Convert Document, and then click From
Word Document to Web Page.
10. On the Create Page From Document page, in the Title box, type Annual Report, and then click
Create.
11. When the page displays, verify that the Word document has been converted to a webpage correctly,
and then click OK. The source document has images which are not converted in this process. This is
expected behavior.
12. On the Not published yet bar, click Publish it.
13. Verify that the page is now included in the current navigation tree.
L7-10
Results: After completing this exercise, you should have created two proxy groups and associated each of
these with a web application. You should have tested that these associations are working correctly and
you should have demonstrated Word document conversion to a webpage.

L8-1
Module 8: Managing Users and Permissions

Exercise 1: Creating a Web Application Policy
Task 1: Create Active Directory security groups
1.
2.
3.
4.
Log on to the 20331B-NYC-DC-08 virtual machine as Contoso\administrator with the password

Pa$$w0rd.
5.
6.
7.
In the Tasks pane, under Builtin, click New, and then click Group
8.
In the Create Group dialog box, in the Group name box, type SharePoint Content Auditors.
9.
Verify that the Group (SamAccountName) name box has populated correctly.
10. Under Group type, verify that Security is selected.

11. Under Group scope, verify that Global is selected.
12. Under Members, click Add.
13. In the Select Users, Contacts, Computers, Service Accounts, or Groups dialog box, in the Enter
the object names to select box, type [email protected], and then click OK.
14. In the Create Group dialog box, click OK.
15. In the Tasks pane, under Builtin, click New, and then click Group
16. In the Create Group dialog box, in the Group name box, type SharePoint Full Control.
17. Verify that the Group (SamAccountName) name box has populated correctly.
19. Under Group scope, verify that Global is selected, and then click OK.
20. In the Tasks pane, under Builtin, click New, and then click Group.
21. In the Create Group dialog box, in the Group name box, type SharePoint Deny Access.
25. In the Tasks pane, under Builtin, click New, and then click Group.
26. In the Create Group dialog box, in the Group name box, type SharePoint Read Only.

Task 2: Create a web application permission policy
L8-2
1.
Log on to the 20331B-NYC-SP-08 virtual machine as Contoso\administrator with the password

Pa$$w0rd.
2.
3.
On the Central Administration website, click Manage web applications.
4.
On the Web Application Management page, click SharePoint - sharepoint.contoso.com80, and

then on the ribbon, click Permission Policy.
5.
In the Manage Permission Policy Levels dialog box, click Add Permission Policy Level.
6.
In the Add Permission Policy Level dialog box, in the Name box, type Content Auditors, under
Site Collection Permissions, select the Site Collection Auditor check box.
7.
Under List Permissions, locate the View Items row, and in that row, select the Grant check box.
8.
Locate the Open Items row, and in that row, select the Grant check box.
9.
Locate the View Versions row, and in that row, select the Grant check box.
10. Under Site Permissions, locate the View Pages row, and in that row, select the Grant check box.
11. Locate the Open row, and in that row, select the Grant check box, and then click Save.
12. In the Manage Permission Policy Levels dialog box, click OK.
Task 3: Create a web application user policy

1.
Click SharePoint - sharepoint.contoso.com80, and then on the ribbon, click User Policy.
2.
In the Policy for Web Application dialog box, click Add Users.
3.
In the Add Users dialog box, click Next.
4.
Under Choose Users, in the Users box, type CONTOSO\SharePoint Content Auditors.
5.
Under Choose Permissions, select the Content Auditors check box, and then click Finish.
6.
7.
In the Add Users dialog box, click Next.
8.
Under Choose Users, in the Users box, type CONTOSO\SharePoint Full Control.
9.
Under Choose Permissions, select the Full Control - Has full control check box, and then click
Finish.
10. In the Policy for Web Application dialog box, click Add Users.
11. In the Add Users dialog box, click Next.
12. Under Choose Users, in the Users box, type CONTOSO\SharePoint Deny Access.
13. Under Choose Permissions, select the Deny All - Has no access check box, and then click Finish.
14. In the Policy for Web Application dialog box, click Add Users.
15. In the Add Users dialog box, click Next.
16. Under Choose Users, in the Users box, type CONTOSO\SharePoint Read Only.

L8-3
17. Under Choose Permissions, select the Full Read - Has full read-only access check box, and then
click Finish.
18. In the Policy for Web Application dialog box, click OK.
Task 4: Test the permission and user policies

1.
2.
3.
On the SharePoint site, in the current navigation, click Documents, and then click new document.
4.
In the Add a document dialog box, click Browse.
5.
In the Choose File to Upload dialog box, browse to the E:\Mod08 folder, click
SampleDocument.docx, and then click Open.
6.
In the Add a document dialog box, click OK.
7.
In the Sample Document row, click the ellipsis (), and verify that the EDIT option is available.
8.
Log on to the 20331B-NYC-DB-08 virtual machine as Contoso\jim with the password Pa$$w0rd.
9.
11. In the Windows Security dialog box, in the User name box, type jim, in the Password box, type
Pa$$w0rd, and then click OK.
12. On the SharePoint site, in the current navigation, click Documents.
13. Verify that you are unable to add a new document (the new document link does not appear in the
document library).
14. In the SampleDocument row, click the ellipsis (), in the Sample Document.docx dialog box, click
the ellipsis (), and then verify that the View Properties option is available, but that the Edit
Properties option is not included.
Results: After completing this exercise, you should have created a new web application policy, and
associated Active Directory security groups with web application policies.
Exercise 2: Creating and Managing SharePoint Groups

Task 1: Add a user to a site's Members SharePoint group
1.
2.
Click Settings, and then click Site settings.
3.
4.
On the Contoso Intranet Portal Members page, click New.
5.
In the Share ' Contoso Intranet Portal' dialog box, in the Enter names, email addresses, or
'Everyone'. box, type [email protected], and then click Share.
Task 2: Verify that the member has the permissions required to edit content
1.
L8-4
2.
Refresh the SharePoint site.
3.
Verify that you are able to add a new document (the new document link appears in the document
library).
4.
In the SampleDocument row, click the ellipsis (), in the Sample Document.docx dialog box, click
the ellipsis (), and then verify that both the View Properties and Edit Properties options are
available.
Task 3: Add a user to a site's Visitors SharePoint group

1.
2.
On the People and Groups page, click Contoso Intranet Portal Visitors.
3.
On the Contoso Intranet Portal Visitors page, click New.
4.
In the Share 'Contoso Intranet Portal' dialog box, in the Enter names, email addresses, or
'Everyone' box, type [email protected], and then click Share.
Task 4: Verify that the visitor has permissions to view the site but not create or edit
content
1.
2.
3.
4.
5.
In the Windows Security dialog box, in the User name box, type ray, in the Password box, type
6.
On the SharePoint site, in the current navigation, click Documents.
7.
Verify that you are unable to add a new document (the new document link does not appear in the
document library).
8.
In the SampleDocument row, click the ellipsis (), in the Sample Document.docx dialog box, click
the ellipsis (), and then verify that the View Properties option is available, but that the Edit
Properties option is not included.
Task 5: Create a new SharePoint group and assign the group the Design permission
level
1.
2.
On the People and Groups page, click Groups, and then click New.
3.
On the Create Group page, in the Name box, type Designers.
4.
Under Give Group Permission to this Site, select Design - Can view, add, update, delete,
approve, and customize., and then click Create.
Task 6: Add a user to the new Designers SharePoint group

1.
On the Designers page, click New.
2.
Task 7: Verify that the designer can customize the appearance of the site
1.

L8-5
2.
3.
4.
5.
In the Windows Security dialog box, in the User name box, type toni, in the Password box, type
6.
On the SharePoint site, click EDIT.
7.
In Edit view, locate the Get started with your site Web Part, and on the Web Part, click REMOVE
THIS.
8.
Close the dialog box that informs you that the getting started tasks are available from the Settings
menu.
9.
Click SAVE.
10. Switch to the 20331B-NYC-SP-08 virtual machine.
11. Click Home, and then on the site Home page, verify that the Get started with your site Web Part
has been removed.
Results: In this exercise, you should have created a new SharePoint group, and added users to both the
default and custom SharePoint groups.
Exercise 3: Creating Custom Permission Levels

Task 1: Create a custom permission level that enables users to view usage data
1.
2.
3.
On the Permissions page, on the ribbon, click Permission Levels.
4.
On the Permissions Levels page, click Add a Permission Level.
5.
On the Add a Permissions Level page, in the Name box, type View Usage Data.
6.
Under Site Permissions, select the View Web Analytics Data check box, and then click Create.
Task 2: Create a new SharePoint group and assign the group the View Usage Data
permission
1.
2.
3.
On the People and Groups page, click Groups, and then click New.
4.
On the Create Group page, in the Name box, type Usage Monitors.
5.
Under Give Group Permission to this Site, select the View Usage Data check box, and then click
Create.
Task 3: Add a user to the new Usage Monitors SharePoint group

1.
On the People and Groups page, click Usage Monitors.
2.
On the Usage Monitors page, click New.
3.
Task 4: Verify that the usage monitor cannot view usage reports
L8-6
1.
2.
Log on as Contoso\will with the password Pa$$w0rd.
3.
4.
5.
In the Windows Security dialog box, in the User name box, type will, in the Password box, type
Pa$$w0rd, and then click OK. Verify that you are denied access to the site.
6.
In Internet Explorer, browse to http://sharepoint.contoso.com/_layouts/usage.aspx. Verify that

you are denied access to the page.
Task 5: Add additional permissions to the View Usage Data permission level
1.
2.
3.
4.
On the Permissions page, on the ribbon, click Permission Levels.
5.
On the Permissions Levels page, click View Usage Data.
6.
On the Edit Permission Level page, under List Permissions, select the View Application Pages
check box, and then click Submit.
Task 6: Verify that the usage monitor can view usage reports
1.
2.
In Internet Explorer, browse to http://sharepoint.contoso.com. Verify that you are denied access to
the site.
3.
In Internet Explorer, browse to http://sharepoint.contoso.com/_layouts/usage.aspx. Verify that

you can access the page.
Results: In this exercise, you should have created a custom permission level, assigned that permission to a
user group, and then tested the user group by using a non-administrative user account.

L8-7

Exercise 1: Managing Permissions and Inheritance
Task 1: Create a new folder in the Documents library, and verify that site members
and visitors can view the folder
1.
2.
On the SharePoint site, click Documents.
3.
In the Documents document library, on the ribbon, on the FILES tab, click New Folder.
4.
In the Create a new folder dialog box, in the Name box, type Reports, and then click Save.
5.
6.
7.
8.
9.
10. On the SharePoint site, in the current navigation, click Documents. Verify that you can see the
Reports folder.
11. Log off.
12. Log on as Contoso\ray with the password Pa$$w0rd.
13. On the Start screen, click Internet Explorer.
15. In the Windows Security dialog box, in the User name box, type ray, in the Password box, type
Reports folder.
Task 2: Disable permission inheritance and define custom permissions for a folder
1.
2.
Next to Reports, click the ellipsis (), in the Reports dialog box, click the ellipsis (), and then click
Shared With.
3.
In the Shared With dialog box, click ADVANCED.
4.
On the Permissions: Reports page, on the ribbon, click Stop Inheriting Permissions.
5.
6.
Select all check boxes, and then, on the ribbon, click Remove User Permissions.
7.
8.
On the ribbon, click Grant Permissions.
9.
In the Share 'Reports' dialog box, in the Enter names, email addresses, or 'Everyone' box, type
[email protected].
10. Click SHOW OPTIONS, clear the Send an email invitation check box, and then click Share.
Task 3: Verify that site members cannot see the folder with custom permissions
L8-8
1.
2.
3.
4.
5.
6.
On the SharePoint site, in the current navigation, click Documents. Verify that you cannot see the
Reports folder.
7.
Log off.
8.
9.

11. In the Windows Security dialog box, in the User name box, type ray, in the Password box, type
Reports folder.
Results: After completing this exercise, you should have defined custom permissions for a folder in a
document library, and tested those permissions by using non-administrative user accounts.
Exercise 2: Managing Site Collection Security

Task 1: Attempt to access a site with a non-authorized account
1.
On the 20331B-NYC-DB-08 virtual machine, if you are not already logged off, log off.
2.
Log on as Contoso\neil with the password Pa$$w0rd.
3.
4.
5.
In the Windows Security dialog box, in the User name box, type neil, in the Password box, type
Pa$$w0rd, and then click OK. Verify that you are denied access to the site and cannot request access
to the site.
Task 2: Enable access requests for the sharepoint.contoso.com site

1.
2.
3.
On the SharePoint site, click Settings, and then click Site settings.
4.
5.
On the Permissions: Contoso Intranet Portal page, on the ribbon, click Access Request Settings.

L8-9
6.
In the Access Requests Settings dialog box, select the Allow access requests check box, in the
Send all access requests to the following e-mail address box, type
Task 3: Request access to a site

1.
2.
In Internet Explorer, navigate to http://sharepoint.contoso.com. Verify that you are still denied
access but that you can now request access to the site.
3.
In the Type your message here box, type I need access to this site, and then click Send request.
Task 4: Approve an access request for a site

1.
2.
3.
On the Site Settings page, under Users and Permissions, click Access requests and invitations.
4.
On the Access Requests page, next to Neil Charney, click the ellipsis (), and then click APPROVE.
Task 5: Attempt to access a site with the approved account

1.
2.
In Internet Explorer, navigate to http://sharepoint.contoso.com. Verify that you now have access to
the site.
Task 6: Configure HTML field security

1.
2.
3.
On the Site Settings page, under Site Collection Administration, click HTML Field Security.
4.
On the HTML Field Security page, click Do not permit contributors to insert iframes from
external domains into pages on this site, and then click OK.
5.
Click Home, and then on the Home page, click EDIT.
6.
In Edit view, on the ribbon, click Edit Source.
7.
In the HTML Source dialog box, on a new line before all existing content, type the following code.
<iframe src="http://www.blocked.contoso.com"></iframe>
8.
In the HTML Source dialog box, click OK, and then verify that SharePoint informs you that some
code has been removed.
9.
On the ribbon, click Edit Source.
10. In the HTML Source dialog box, verify that the code you added has been removed, and then click
OK.
11. Close all open windows, saving any changes, by clicking OK.
Results: After completing this exercise, you should have enabled access requests and configured HTML
field security for a SharePoint site.
Exercise 3: Enable anonymous access to a site

Task 1: Configure a DNS record for the www.contoso.com web application
L8-10
1.
2.
3.
In DNS Manager, expand Forward Lookup Zones, and then click Contoso.com.
4.
Right-click Contoso.com, and then click New Host (A or AAAA).
5.
In the New Host dialog box, in the Name box, type www, in the IP address box, type 172.16.1.21,
6.
7.
In the New Host dialog box, click Done.
Task 2: Create a service account for the www.contoso.com web application

application pool
1.
2.
3.
4.
In the Create User dialog box, in the Full name box, type WWW Application Pool.
5.
In the User UPN logon box, type WWWAppPool, and then verify that the User SamAccountName
6.
In the Password and Confirm password boxes, type Pa$$w0rd.
7.

1.
2.
3.
4.
5.
6.
On the Register Managed Account page, in the User name box, type CONTOSO\WWWAppPool,
in the Password box, type Pa$$w0rd, and then click OK.
Task 4: Create and configure a new web application

1.
2.
3.
4.
In the Create New Web Application dialog box, under IIS Web Site, in the Name box, type WWW
- 80.
5.

L8-11
6.
In the Host Header box, type www.contoso.com.
7.
Under Application Pool, in the Application pool name box, type WWW - 80.
8.
In the Configurable list, click CONTOSO\WWWAppPool, and then click OK.
9.
Task 5: Create a root site collection

1.
2.
3.
On the Create Site Collection page, under Web Application, verify that http://www.contoso.com
is selected. If it is not currently selected, click the current web application, click Change Web
Application, and then click WWW - 80.
4.
Under Title and Description, in the Title box, type Internet Site.
5.
Under Template Selection, on the Publishing tab, click Publishing Portal.
6.
7.
Task 6: Enable anonymous access for the www.contoso.com web application

1.
On the Application Management page, under Web Applications, click Manage web applications.
2.
On the Web Applications Management page, click WWW-80, and then, on the ribbon, click
Authentication Providers.
3.
In the Authentication Providers dialog box, click Default.
4.
In the Edit Authentication dialog box, select the Enable anonymous access check box, and then
click Save.
5.
In the Authentication Providers dialog box, click Close dialog.
6.
On the ribbon, click Anonymous Policy.
7.
In the Anonymous Access Restrictions dialog box, click Deny Write, and then click Save.
Task 7: Enable anonymous access for the www.contoso.com site collection.

1.
In Internet Explorer, browse to http://www.contoso.com.
2.
3.
4.
5.
On the Permissions page, on the ribbon, click Anonymous Access.
6.
In the Anonymous Access dialog box, click Entire Web site, and then click OK.
7.
Task 8: Test the www.contoso.com web application to ensure you can access it
without providing credentials
1.
2.
In Internet Explorer, navigate to http://www.contoso.com. Verify that you can access the site
without providing credentials.
3.
Results: After completing this exercise, you should have configured a site for anonymous access.
L8-12

L9-1
Module 9: Configuring Authentication for SharePoint 2013
Lab: Configuring SharePoint 2013 to Use

Federated Identities
Exercise 1: Configuring AD FS to Make the Web Application a Relying
Party
Task 1: Configure a relying party in AD FS
1.
Start the 20331B-SEA-ADFS-09 virtual machine. Wait for the virtual machine to display the logon
2.
3.
4.
5.
Log on to the SEA-ADFS1 virtual machine as RESEARCH\Administrator with password Pa$$w0rd.
6.
On the Start screen, type AD FS Management, and then press Enter.
7.
In the AD FS window, in the Actions pane, click Add Relying Party Trust.
8.
On the Welcome to the Add Relying Party Trust Wizard page, click Start.
9.
On the Select Data Source page, select Enter data about the relying party manually, and then
click Next.
10. On the Specify Display Name page, in the Display name text box, type Contoso SharePoint
Intranet, and then click Next.
11. On the Choose Profile page, ensure AD FS profile is selected, and then click Next.
12. On the Configure Certificate page, leave the token encryption certificate unconfigured and click
Next.
13. On the Configure URL page, select Enable support for the WS-Federation Passive protocol.
14. In the Relying party WS-Federation Passive protocol URL text box, type
https://sharepoint.contoso.com/_trust/, and then click Next.
15. On the Configure Identifiers page, in the Relying party trust identifier text box, type
urn:contoso:sharepoint.contoso.com.
16. Click Add, and then click Next.
17. On the Choose Issuance Authorization Rules page, ensure Permit all users to access this relying
party is selected, and then click Next.
18. On the Ready to Add Trust page, click Next.
19. On the Finish page, ensure Open the Edit Claim Rules dialog for this relying party trust when
the wizard closes is selected, and then click Close.
Task 2: Configure a claim rule
L9-2
1.
In the Edit Claim Rules for Contoso SharePoint Intranet dialog box, on the Issuance Transform
Rules tab, click Add Rule.
2.
In the Add Transform Claim Rule Wizard dialog box, in the Claim rule template drop-down box,
ensure that Send LDAP Attributes as Claims is selected, and then click Next.
3.
On the Configure Rule page, in the Claim rule name text box, type Contoso SharePoint Claim
Rule.
4.
In the Attribute store drop-down box, click Active Directory.
5.
In the Mapping of LDAP attributes to outgoing claim types table, under LDAP Attribute, select
SAM-Account-Name.
6.
Under Outgoing Claim Type, select E-Mail Address.
7.
In the second row, in the LDAP Attribute column, select User-Principal-Name.
8.
In the second row, in the Outgoing Claim Type column, select UPN.
9.
Click Finish
10. In the Edit Claim Rules for Contoso SharePoint Intranet dialog box click OK.
Task 3: Export the token-signing certificate

1.
In the AD FS Management window, in the navigation pane, expand Service, and then click
Certificates.
2.
In the Certificates pane, select the certificate under Token-signing.
3.
In the Actions pane, click View Certificate.
4.
In the Certificate dialog box, on the Details tab, click Copy to File.
5.
On the Welcome to the Certificate Export Wizard page, click Next.
6.
On the Export File Format page, ensure that DER encoded binary X.509 (.CER) is selected, and
then click Next.
7.
On the File to Export page, click Browse.
8.
In the Save As dialog box, in the navigation pane, click Desktop.
9.
In the File name text box, type ContosoResearchTokenSigning, and then click Save.
10. On the File to Export page, click Next.

11. On the Completing the Certificate Export Wizard page, click Finish.
12. In the Certificate Export Wizard message box, click OK.
13. Close the Certificate dialog box.
14. Close the AD FS window.
15. On the Windows taskbar, click File Explorer.
16. In File Explorer, click in the address bar, type \\sharepoint.contoso.com\Share, and then press
Enter. If you are prompted for credentials, log in as CONTOSO\Administrator with password
Pa$$w0rd.
17. Drag the ContosoResearchTokenSigning.cer file from the desktop to the Share folder.

L9-3
Results: After completing this exercise, you should have configured AD FS to provide federated
authentication to a SharePoint web application.
Exercise 2: Configuring SharePoint to Trust AD FS as an Identity Provider

Task 1: Import the token-signing certificate
1.

Pa$$w0rd.
2.
3.
At the command prompt, type the following command, and then press Enter.
$cert = New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2("E:\Share\ContosoResea
rchTokenSigning.cer")
4.
New-SPTrustedRootAuthority -Name "Contoso Research ADFS Token Signing" -Certificate

$cert
Task 2: Map incoming claims to SharePoint claims

1.
In the SharePoint 2013 Management Shell window, at the command prompt, type the following
command, and then press Enter.
$emailClaimMapping = New-SPClaimTypeMapping -IncomingClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
2.
$upnClaimMapping = New-SPClaimTypeMapping -IncomingClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" IncomingClaimTypeDisplayName "UPN" -SameAsIncoming
Task 3: Register AD FS as a trusted identity provider in SharePoint

1.
In the SharePoint 2013 Management Shell window, at the command prompt, type the following
command, and then press Enter.
$realm = "urn:contoso:sharepoint.contoso.com"
2.
$signInURL = "https://sea-adfs1.contosoresearch.net/adfs/ls"
3.
New-SPTrustedIdentityTokenIssuer -Name "Contoso Research AD FS" -Description "AD FS

deployment at Contoso Research" -realm $realm -ImportTrustCertificate $cert ClaimsMappings $emailClaimMapping,$upnClaimMapping -SignInUrl $signInURL IdentifierClaim $emailClaimMapping.InputClaimType
Results: After completing this exercise, you should have configured a SharePoint 2013 deployment to
trust an AD FS deployment as an identity provider.
Exercise 3: Configuring the Web Application to Use the AD FS Identity

Provider
Task 1: Configure the web application to use the AD FS identity provider
L9-4
1.
On the 20331B-NYC-SP-09 virtual machine, on the Start screen, type SharePoint 2013 Central
Administration, and then press Enter.
2.
Under Application Management, click Manage web applications.
3.
Select the SharePoint - sharepoint.contoso.com80 web application.
4.
On the ribbon, on the Web Applications tab, click Authentication Providers.
5.
In the Authentication Providers dialog box, under Zone, click Extranet.
6.
In the Edit Authentication dialog box, under Claims Authentication Types, select Trusted Identity
Provider, and then select Contoso Research AD FS.
7.
Click Save.
8.
Close the Edit Authentication dialog box.
Task 2: Grant federated users access to the site collection

1.
On the ribbon, on the Web Applications tab, click User Policy.
2.
3.
In the Add Users dialog box, select the Extranet zone, and then click Next.
4.
In the Choose Users section, click the Browse icon.
5.
In the Select People and Groups dialog box, click All Users, and then click All Users (Contoso
Research AD FS).
6.
Click Add, and then click OK.
7.
In the Choose Permissions section, select Full Read, and then click Finish.
8.
In the Policy for Web Application dialog box, click OK.
9.
In Internet Explorer, browse to https://sharepoint.contoso.com.
10. On the Sign In page, select Contoso Research AD FS.

11. Log in as RESEARCH\Administrator with the password Pa$$w0rd.
12. Verify that you have access to the site.
Results: After completing this exercise, you should be able to log on to the SharePoint site at
https://sharepoint.contoso.com with a set of RESEARCH domain credentials.

L10-1
Module 10: Securing a SharePoint 2013 Deployment
Lab A: Hardening a SharePoint 2013 Server

Farm
Exercise 1: Configuring SharePoint and SQL Server to Communicate Over

Non-Standard Ports
Task 1: Configure SQL Server to Use a Non-Standard TCP Port
1.
2.
3.
4.

Pa$$w0rd.
5.
On the Start screen, type SQL Server Configuration Manager, and then press Enter.
6.
In SQL Server Configuration Manager, in the navigation pane, expand SQL Server Network
Configuration, and then click Protocols for MSSQLSERVER.
7.
In the details pane, right-click the TCP/IP row, and then click Properties.
8.
In the TCP/IP Properties dialog box, on the IP Addresses tab, locate the IPAll section.
9.
In the IPAll section, in the TCP Port row, change the port number to 55555, and then click OK.
10. In the Warning dialog box, click OK.

11. In the navigation pane, click SQL Server Services.
12. In the details pane, right-click SQL Server (MSSQLSERVER), and then click Restart.
13. Close SQL Server Configuration Manager.
Task 2: Configure SharePoint to Communicate with SQL Server on a Specific Port

1.

Pa$$w0rd.
2.
3.
In the Internet Explorer address bar, type sharepoint.contoso.com, and then press Enter.
4.
5.
Verify that the page displays an error message.
Note: This is because SharePoint is currently unable to communicate with the SQL Server
instance on the database server.
6.
7.
On the Start screen, type cliconfg, and then press Enter.
L10-2
8.
In SQL Server Client Network Utility, on the Alias tab, make sure ContosoDB is selected, and then
click Edit.
9.
In the Edit Network Library Configuration dialog box, clear the Dynamically determine port
check box.
10. In the Port number box, type 55555, and then click OK.
11. In SQL Server Client Network Utility, click OK.
13. In the Internet Explorer address bar, type sharepoint.contoso.com, and then press Enter.
14. If you are prompted for credentials, log on as Contoso\Administrator with the password Pa$$w0rd.
15. Verify that the page loads successfully.
Results: After completing this exercise, you should have configured SharePoint and SQL Server to
communicate over a non-standard TCP port.
Exercise 2: Configuring Firewalls for SharePoint Server Farms

Task 1: Enable the firewall on the database server
1.
2.
On the Start screen, type Windows Firewall, and then press Enter.
3.
In the Windows Firewall with Advanced Security window, in the Overview section, click Windows
Firewall Properties.
4.
In the Windows Firewall with Advanced Security on Local Computer dialog box, on the Domain
Profile tab, in the Firewall state list, click On (recommended), and then click OK.
5.
Close the Windows Firewall with Advanced Security window.
6.
7.
8.
9.
10. Verify that the page displays HTTP 500 Internal Server Error.
Note: This is because the firewall on the database server is currently preventing SharePoint
from communicating with the database server.
Task 2: Configure firewall exceptions on the database server

1.
2.

L10-3
3.
In the Windows Firewall with Advanced Security window, in the navigation pane, click Inbound
Rules.
4.
In the Actions pane, click New Rule.
5.
In the New Inbound Rule Wizard dialog box, on the Rule Type page, click Port, and then click
Next.
6.
On the Protocol and Ports page, make sure TCP is selected.
7.
In the Specific local ports box, type 55555, and then click Next.
8.
On the Action page, make sure Allow the connection is selected, and then click Next.
9.
On the Profile page, leave Domain selected, clear the Private and Public check boxes, and then click
Next.
10. On the Name page, in the Name box, type SQL Server inbound TCP traffic from SharePoint, and
then click Finish.
11. Close the Windows Firewall with Advanced Security window.
12. Switch to the 20331B-NYC-SP-10 virtual machine.
14. In the Internet Explorer address bar, type sharepoint.contoso.com, and then press Enter.
Task 3: Enable the firewall on the SharePoint server

1.
2.
In the Windows Firewall with Advanced Security window, in the Overview section, click Windows
Firewall Properties.
3.
In the Windows Firewall with Advanced Security on Local Computer dialog box, on the Domain
Profile tab, in the Firewall state list, click On (recommended), and then click OK.
4.
In the navigation pane, click Inbound Rules.
5.
Review the existing inbound rules, and notice that they include various rules to allow communication
between servers in the SharePoint farm:
o
The SharePoint - sharepoint.contoso.com80 rule allows the SharePoint web application to

receive TCP traffic over port 80.
The SharePoint Central Administration v4 rule allows the Central Administration web
application to receive TCP traffic over port 50000.
The SharePoint Search rule allows various components of the search service to receive TCP
traffic over ports 16500-16519.
The SharePoint Web Services rule allows various Windows Communication Foundation (WCF)
based SharePoint web services to listen on TCP ports 32843-32845.
The SPUserCodeV4 rule enables the user code service for sandboxed solutions to listen on TCP
port 32846.
6.
Close the Windows Firewall with Advanced Security window.
7.
L10-4
8.
9.

Note: You do not need to configure an inbound firewall exception for SQL Server traffic on
port 55,555 on the SharePoint server, because database communication takes place on the
outbound port 55,555.
Results: After completing this exercise, you should have configured firewalls on a database server and a
SharePoint server.

L10-5

Exercise 1: Configuring Blocked File Types
Task 1: Block bitmap file types at the web application level
1.
On the 20331B-NYC-SP-10 virtual machine, on the Start screen, type SharePoint 2013 Central
Administration, and then press Enter.
2.
On the Central Administration website, under Application Management, click Manage web
applications.
3.
4.
On the ribbon, on the Web Applications tab, in the Security group, click Blocked File Types.
5.
In the Blocked File Types dialog box, on a new line, type bmp.
6.
On a new line, type dib, and then click OK.
Task 2: Verify file type blocking

1.
2.
3.
In the Quick Launch navigation pane, click Site Contents.
4.
On the Site Contents page, click Site Assets.
5.
On the Site Assets page, click new document.
6.
In the Add a document dialog box, click Browse.
7.
In the Choose Files to Upload dialog box, browse to the E:\Mod10 folder, click
ContosoHeader.bmp, and then click Open.
8.
In the Add a document dialog box, click OK.
9.
In the Error dialog box, verify that you receive an error message that states your file has been
blocked by the administrator, and then click GO BACK TO SITE.
10. On the Site Assets page, click new document.

11. In the Add a document dialog box, click Browse.
12. In the Choose Files to Upload dialog box, browse to the E:\Mod10 folder, click
ContosoHeader.jpg, and then click Open.
13. In the Add a document dialog box, click OK.
14. Verify that the image is added to the Site Assets page.
Results: After completing this exercise, you should have configured blocked file types to prevent users
from uploading .bmp or .dib files.
Exercise 2: Configuring Web Part Security

Task 1: Create a Web Part Connection
L10-6
1.
2.
3.
4.
When the page loads, notice that the Documents Web Part displays three documents.
5.
On the toolbar at the top of the page, click EDIT.
6.
Click in the content area below the Documents Web Part.
7.
On the ribbon, on the INSERT tab, click Web Part.
8.
In the Categories list, click Filters.
9.
In the Parts list, click Current User Filter, and then click Add.
10. Click on the new Web Part, which is rendered as an empty rectangle.
11. On the ribbon, on the WEB PART tab, click Web Part Properties.
12. On the Current User Filter Web Part, on the drop-down menu, point to Connections, point to Send
Filter Values To, and then click Documents.
13. In the Internet Explorer blocked a pop-up from sharepoint.contoso.com message box, on the
Options for this site drop-down menu, click Always allow.
14. In the Message from webpage dialog box, click OK.
15. In the Windows Internet Explorer dialog, click Retry.
16. In the Choose Connection dialog box, in the Connection Type list, click Get Filter Values From,
and then click Configure.
17. In the Configure Connection dialog box, in the Consumer Field Name list, click Created By, and
then click Finish.
18. On the ribbon, on the PAGE tab, click Save.
19. Notice that the Documents web part no longer displays any documents. The documents are being
filtered out because you did not create them. If SharePoint displays a Save Conflict dialog box, click
Overwrite the Page, and then click OK.
Task 2: Configure Web Part security settings

1.
On the Start screen, type SharePoint 2013 Central Administration, and then press Enter.
2.
On the Central Administration website, under Application Management, click Manage web
applications.
3.
4.
On the ribbon, on the WEB APPLICATIONS tab, in the Security group, click Web Part Security.
5.
In the Security For Web Part Pages dialog box, under Web Part Connections, click Prevents users
from creating connections between Web Parts, and helps to improve security and
performance.
6.
Under Online Web Part Gallery, click Prevents users from accessing the Online Web Part
Gallery, and helps to improve security and performance, and then click OK.

L10-7
7.
8.
9.
Verify that the Documents Web Part is no longer filtering the list of documents.
10. On the toolbar at the top of the page, click EDIT.

11. Click on the Current User Filter Web Part, which is rendered as an empty rectangle.
12. On the ribbon, on the WEB PART tab, click Web Part Properties.
13. Notice that the Current User Filter Web Part displays a warning message stating that the filter is not
connected.
14. On the Current User Filter Web Part, on the drop-down menu, verify that there is no longer a menu
option for connecting the Web Part.
Results: After completing this exercise, you should have configured Web Part security settings to prevent
users from connecting Web Parts or accessing the Online Web Part Gallery.
Exercise 3: Implementing Security Auditing

Task 1: Configure site collection audit settings
1.
2.
3.
4.
5.
On the Site Settings page, under Site Collection Administration, click Site collection audit
settings.
6.
On the Configure Audit Settings page, under Automatically trim the audit log for this site, click
Yes.
7.
Under Optionally, specify the number of days of audit log data to retain, in the box, type 28.
8.
Under Documents and Items, select the following check boxes:
9.
Moving or copying items to another location in the site
Deleting or restoring items
Under Lists, Libraries, and Sites, select the Editing users and permissions check box, and then click
OK.
Task 2: Create some audit data

1.
On the Quick Launch navigation menu, click Documents.
2.
On the ribbon, on the LIBRARY tab, click Library Settings.
3.
On the Document/Settings page, under Permissions and Management, click Permissions for this
document library.
L10-8
4.
On the ribbon, on the PERMISSIONS tab, click Stop Inheriting Permissions.
5.
6.
Select the Contoso Intranet Portal Visitors check box, and then on the ribbon, click Remove User
Permissions.
7.
8.
9.
Click the StatementOfWork.docx row, and then on the ribbon, on the FILES tab, click Delete
Document.
Task 3: View the audit reports

1.
2.
On the Site Settings page, under Site Collection Administration, click Audit log reports.
3.
On the View Auditing Reports page, under Content Activity Reports, click Deletion.
4.
On the Customize Report page, under File Location, click Browse.
5.
In the Select List or Library dialog box, click Documents, and then click OK.
6.
On the Customize Report page, click OK.
7.
On the Operation Completed Successfully page, click Click here to view the report.
The report loads in an Excel Web Access browser window.
8.
Review the report, and verify that it records the document you deleted in the previous task.
9.
Close the Excel Web Access browser window.
10. On the Operation Completed Successfully page, click OK.

11. On the Site Settings page, under Site Collection Administration, click Audit log reports.
12. On the View Auditing Reports page, under Security And Site Settings Reports, click Security
settings.
13. On the Customize Report page, under File Location, click Browse.
14. In the Select List or Library dialog box, click Documents, and then click OK.
15. On the Customize Report page, click OK.
16. On the Operation Completed Successfully page, click Click here to view the report.
The report loads in an Excel Web Access browser window.
17. Review the report, and verify that it refers to the permissions changes you made in the previous task.
Results: After completing this exercise, you should have configured site collection audit settings.

L11-1
Module 11: Managing Taxonomy
Lab A: Configuring Content Type

Propagation
Exercise 1: Creating Content Types for Propagation
Task 1: Create the Invoice content type
1.
2.
3.
4.

Pa$$w0rd.
5.
6.
7.
8.
9.
On the Site Settings page, under Web Designer Galleries, click Site columns.
10. On the Site Columns page, click Create.

11. On the Create Column page, in the Column name box, type Supplier.
12. Under Group, click New group, and then in the box, type Contoso Columns, and then click OK.
14. On the Create Column page, in the Column name box, type Payment Due Date.
15. Under Name and Type, click Date and Time.
16. Under Group, in the Existing group list, click Contoso Columns, and then click OK.
18. On the Create Column page, in the Column name box, type Contoso Department.
21. On the Create Column page, in the Column name box, type Payment Amount.
22. Under Name and Type, click Currency.
24. On the site breadcrumb trail, click Site Settings.
25. On the Site Settings page, under Web Designer Galleries, click Site content types.
26. On the Site Content Types page, click Create.
27. On the New Site Content Type page, in the Name box, type Invoice.
28. In the Select parent content type from list, click Document Content Types.
29. In the Parent Content Type list, click Document.
L11-2
30. In the Group section, click New group, and then in the box, type Contoso Content Types, and then
click OK.
31. On the Site Content Type page, under Columns, click Add from existing site columns.
32. On the Add Columns page, in the Select columns from list, click Contoso Columns.
33. In the Available columns list box, click Contoso Department, Payment Amount, Payment Due
Date, and Supplier, click Add, and then click OK
Note: To select multiple items, hold down the Ctrl key and click each item.
Task 2: Create the Contract content type

1.
2.
3.
On the Site Columns page, click Create.
4.
On the Create Column page, in the Column name box, type Client.
5.
Under Group, in the Existing group list, click Contoso Columns, and then click OK.
6.
7.
On the Create Column page, in the Column name box, type Final Effective Date.
8.
Under Name and Type, click Date and Time.
9.
Under Group, in the Existing group list, click Contoso Columns, and then click OK.

11. On the Create Column page, in the Column name box, type Contract Owner.
12. Under Name and Type, click Person or Group.
14. On the site breadcrumb trail, click Site Settings.
16. On the Site Content Types page, click Create.
17. On the New Site Content Type page, in the Name box, type Contract.
18. In the Select parent content type from list, click Document Content Types.
19. In the Parent Content Type list, click Document.
20. In the Group section, in the Existing group list, click Contoso Content Types, and then click OK.
21. On the Site Content Type page, under Columns, click Add from existing site columns.
23. In the Available columns list box, click Client, Contract Owner, and Final Effective Date, click Add,
and then click OK.

L11-3
Results: After completing this exercise, you should have created several site columns and two content
types.
Exercise 2: Publishing Content Types Across Site Collections

1.

password Pa$$w0rd.
2.
3.
4.
5.
In the Create User dialog box, in the Full name box, type SharePoint General MMS.
6.
In the User UPN logon box, type ContosoMMS.
7.
Verify that the User SamAccountName logon boxes have automatically populated with the
corresponding user name.
8.
9.
Click Other password options, select the Password never expires and User cannot change

1.
2.
3.
4.
5.
6.
On the Register Managed Account page, in the User name box, type CONTOSO\ContosoMMS, in

1.
2.
Locate the Managed Metadata Web Service service, and then in that row, click Start.

1.
Click Application Management, and then under Service Applications, click Manage service
applications.
2.
On the ribbon, click New, and then click Managed Metadata Service.
3.
In the Name box, type Contoso Managed Metadata Service.
4.
In the Database Name box, type ContosoMMS.
L11-4
5.
Click Create new application pool, and then in the Application pool name box, type
ContosoMMSAppPool.
6.
In the Application Pool section, in the Configurable list, click CONTOSO\ContosoMMS.
7.
In the Content Type hub box, type http://sharepoint.contoso.com, and then click OK.
8.
If SharePoint displays a Message from webpage dialog box which indicates that the Content Type
Syndication Hub feature failed to activate, click OK.
9.
10. In the Windows Security dialog, in the User name box type CONTOSO\Administrator, in the
Password box type Pa$$w0rd, and then click OK.
11. Click Settings and then click Site settings.
12. On the Site Settings page, under Site Collection Administration, click Site collection features.
13. On the Site Collection Features page, in the Content Type Syndication Hub row, click Activate.
14. Refresh the page and verify that the Content Type Syndication Hub feature now has a status of
Active.
Task 5: Publish the content types

1.
Click Home.
2.
If you are prompted for credentials, log on as CONTOSO\Administrator with the password
Pa$$w0rd.
3.
4.
On the Site Settings page, under Web Designer Galleries, click Site content types.
5.
On the Site Content Types page, under Contoso Content Types, click Contract.
6.
Under Settings, click Manage publishing for this content type.
7.
On the Content Type Publishing: Contract page, make sure Publish is selected, and then click OK.
8.
On the Site Content Type page, on the site breadcrumb trail, click Site Content Types.
9.
On the Site Content Types page, under Contoso Content Types, click Invoice.
10. Under Settings, click Manage publishing for this content type.
11. On the Content Type Publishing: Invoice page, make sure Publish is selected, and then click OK.
13. On the Start screen, type SharePoint 2013 Central Administration, and then press Enter.
14. On the Quick Launch navigation menu, click Monitoring.
15. On the Monitoring page, under Timer Jobs, click Review job definitions.
16. On the Job Definitions page, click Content Type Subscriber.
17. On the Edit Timer Job page, click Run Now.
18. In the Internet Explorer address bar, type http://sharepoint.contoso.com/projects/P1, and then
press Enter.
20. On the Settings menu, click Site settings.

L11-5
22. On the Site Content Types page, verify that the list of content types includes a group named
Contoso Content Types.
23. Verify that the Contoso Content Types group includes content types named Contract and Invoice.
Results: After completing this exercise, you should have provisioned a Managed Metadata Service
application instance and published content types across site collection boundaries.
Lab B: Configuring and Using Managed

Metadata Term Sets
Exercise 1: Configuring the Managed Metadata Service
Task 1: Assign term store administrators
L11-6
1.
2.
Under Application Management, click Manage service applications.
3.
On the list of service applications, select the Contoso Managed Metadata Service row, and then on
the ribbon, click Manage.
4.
On the Term Store Management Tool page, in the Term Store Administrators box, after the
existing entry, type contoso\jim.
5.
Click Check Names, and then click Save.
Results: After completing this exercise, you will be able to configure term store administrators.
Exercise 2: Creating Term Sets and Terms

Task 1: Create the Department term set
1.
On the Term Store Management Tool page, in the navigation pane, click Contoso Managed
Metadata Service, and then click New Group.
2.
Type Organization, and then press Enter.
3.
On the Organization drop-down menu, click New Term Set.
4.
Type Department, and then press Enter.
5.
On the Department drop-down menu, click Create Term.
6.
Type Marketing, and then press Enter.
7.
Type Finance, and then press Enter.
8.
Type IT, and then press Enter.
9.
Type Sales, and then press Enter.
Task 2: Create the Supplier term set

1.
On the Organization drop-down menu, click New Term Set.
2.
Type Supplier, and then press Enter.
3.
On the Supplier drop-down menu, click Create Term.
4.
Type Litware, Inc., and then press Enter.
5.
Type Proseware, Inc., and then press Enter.
6.
Type Northwind Traders, and then press Enter.
7.
Type Trey Research, and then press Enter.

L11-7
8.
Type Wide World Importers, and then press Enter.
9.
Results: After completing this exercise, you will be able to create term set groups, term sets, and terms.
Exercise 3: Consuming Term Sets

Task 1: Replace the Supplier site column with a managed metadata column
1.
2.
In the Internet Explorer address bar, type http://sharepoint.contoso.com, and then press Enter.
3.
4.
5.
6.
7.
On the Create Column page, in the Column name box, type Supplier (MMS).
8.
9.
Under Group, in the Existing group list, click Contoso Columns.
10. Under Term Set Settings, expand Contoso Managed Metadata Service, expand Organization,
click Supplier, and then click OK.
Task 2: Replace the Contoso Department column with a managed metadata column
1.
2.
On the Create Column page, in the Column name box, type Contoso Department (MMS).
3.
4.
Under Group, in the Existing group list, click Contoso Columns.
5.
Under Term Set Settings, expand Contoso Managed Metadata Service, expand Organization,
click Department, and then click OK.
Task 3: Edit and republish the Invoice content type

1.
On the Site Columns page, on the site breadcrumb trail, click Site Settings.
2.
On the Site Settings page, under Web Designer Galleries, click Site content types.
3.
On the Site Content Types page, under Contoso Content Types, click Invoice.
4.
On the Site Content Type page, in the Columns list, click Supplier.
5.
On the Change Content Type Column page, click Remove.
6.
7.
On the Site Content Type page, in the Columns list, click Contoso Department.
8.
On the Change Content Type Column page, click Remove.
9.
L11-8
10. On the Site Content Type page, under the list of columns, click Add from existing site columns.
12. In the Available columns list box, click Contoso Department (MMS) and Supplier (MMS), and
then click Add.
14. On the Add Columns page, click OK.
15. On the Site Content Type page, click Manage publishing for this content type.
16. On the Content Type Publishing: Invoice page, make sure Republish is selected, and then click OK.
18. On the Start screen, type SharePoint 2013 Central Administration, and then press Enter.
19. On the Quick Launch navigation menu, click Monitoring.
20. On the Monitoring page, under Timer Jobs, click Review job definitions.
21. On the Job Definitions page, click Content Type Subscriber.
22. On the Edit Timer Job page, click Run Now.
Task 4: Verify that the republished content type and managed metadata columns
behave as expected
1.
In the Internet Explorer address bar, type http://sharepoint.contoso.com/projects/P1, and then

press Enter.
2.
3.
4.
On the ribbon, on the Library tab, click Library Settings.
5.
On the Settings page, under General Settings, click Advanced settings.
6.
On the Advanced Settings page, under Allow management of content types, click Yes, and then
click OK.
7.
On the Settings page, under Content Types, click Add from existing site content types.
8.
On the Add Content Types page, in the Select site content types from list, click Contoso Content
Types.
9.
In the Available Site Content Types list box, click Invoice, click Add, and then click OK.
10. On the site breadcrumb trail, click Documents.

11. On the Document page, click new document.
12. In the Add a document dialog box, click Browse.
13. Browse to the E:\Mod11 folder, select the Invoice.docx file, and then click Open.
14. In the Add a document dialog box, click OK.
15. In the Documents Invoice.docx dialog box, in the Content Type list, click Invoice.
16. In the Title box, type Stationery Invoice.
17. In the Payment Amount box, type 89.50.
18. In the Payment Due Date box, type 4/14/2013.

L11-9
19. Next to the Contoso Department (MMS) box, click the tag icon.
20. In the Select: Contoso Department (MMS) dialog box, click Finance, click Select, and then click OK.
21. Next to the Supplier (MMS) box, click the tag icon.
22. In the Select: Supplier (MMS) dialog box, click Litware, Inc., click Select, and then click OK.
23. In the Documents Invoice.docx dialog box, click Save.
Results: After completing this exercise, you will be able to use managed metadata term sets in site
columns and content types.

L12-1
Module 12: Configuring User Profiles

Exercise 1: Creating a User Profile Service Application
Task 1: Create a service account for the service application
1.
2.
3.
4.

password Pa$$w0rd.
5.
6.
7.
8.
In the Create User dialog box, in the Full name box, type Profile Service.
9.
In the User UPN logon box, type ProfileService, verify that the User SamAccountName logon
10. In the Password and Confirm password boxes, type Pa$$w0rd.

Task 2: Grant the SPFarmAccount the Replicating Directory Changes permission

1.
Right-click Contoso (local), and then click Properties.
2.
In the Contoso dialog box, in the Extensions panel, on the Security tab, click Add.
3.
In the Select Users, Computers, Service Accounts, or Groups dialog box, in the Enter the object
names to select box, type SPFarm, and then click OK.
4.
Under Permissions for SPFarm, locate the Replicating Directory Changes permission, in that row,
select the Allow check box, and then click OK.

1.
2.
3.
In Central Administration, click Security, under General Security, click Configure managed
accounts.
4.
5.
On the Register Managed Account page, in the User name box, type CONTOSO\ProfileService, in
Task 4: Start the User Profile Service instance

1.
Click System Settings.
2.
On the System Settings page, under Servers, click Manage services on server.
3.
Locate the User Profile Service service, and then in that row, click Start.
4.
Check the status of the User Profile Service service, refresh the page, until the status changes to
Started.
Task 5: Create a new User Profile Service application instance
L12-2
1.
2.
On the Application Management page, under Service Applications, click Manage service
applications.
3.
On the Manage Service Applications page, on the ribbon, click New, and then click User Profile
Service Application.
4.
In the Create New User Profile Service Application dialog box, in the Name box, type Contoso
UPSA.
5.
In the Application pool name box, type ContosoUPSAAppPool.
6.
In the Configurable list, click CONTOSO\ProfileService, and then click Create.
7.
In the Create New User Profile Service Application dialog box, click OK.
8.
Refresh the Manage Service Applications page, and then verify that the Contoso UPSA service
application and Contoso UPSA service application proxy are included in the list of service
applications.
Results: After completing this exercise, you should have created a new instance of the User Profile Service
application.
Exercise 2: Configuring Directory Import

Task 1: Configure the User Profile Synchronization Service application instance for
import-only synchronization
1.
On the Manage Service Applications page, click Contoso UPSA (you must click the name in the
User Profile Service Application row, not the User Profile Service Application Proxy row).
2.
If the Sorry, something went wrong page appears, click Back to Manage Service Applications
(the Internet Explorer Back button), and repeat step 1.
Note: If this occurs more than once, wait for five minutes and then retry.
3.
On the Manage Profile Service page, under Synchronization, click Configure Synchronization
Settings.
4.
On the Configure Synchronization Settings page, under Synchronization Options, click Use
SharePoint Active Directory Import, and then click OK.

L12-3
Task 2: Configure a connection to Active Directory

1.
Connections.
2.
On the Synchronization Connections page, click Create New Connection.
3.
On the Add new synchronization connection page, in the Connection Name box, type Contoso
Domain.
4.
Under Connection Settings, in the Fully Qualified Domain Name box, type contoso.com.
5.
In the Account name box, type CONTOSO\SPFarm.
6.
7.
Under Containers, click Populate Containers, wait for the containers to load before you proceed to
the next step.
8.
Click Select All, and then, when the container is selected, click OK.
Task 3: Configure profile synchronization

1.
2.
applications.
3.
4.
Timer Job.
5.
On the Edit Timer Job page, if the timer job is disabled, click Enable.
6.
7.
applications.
8.
9.
On the Manage Profile Service page, under Synchronization, click Start Profile Synchronization.
10. On the Start Profile Synchronization page, click Start Full Synchronization, and then click OK.
11. On the Manage Profile Service page, under Profile Synchronization Settings, verify that the
Profile Synchronization Status is Synchronizing. You may need to refresh the page. Periodically
refresh the page and do not continue until the status returns to Idle. Depending on the speed of your
host computer, you may not see the Synchronizing status; if the status is Idle, and the number of
profiles is more than zero, you can continue.
Task 4: Test profile synchronization

1.
On the Manage Profile Service page, under People, click Manage User Profiles.
2.
On the Manage User Profiles page, in the Find profiles box, type Jim, and then click Find.
3.
Under Account name, click CONTOSO\Jim, and then click Edit My Profile.
4.
L12-4
Results: After completing this exercise, you should have configured and validated a user profile import
from Active Directory.

L12-5

Exercise 1: Configuring My Sites
Task 1: Configure a DNS record for the My Site web application
1.
2.
3.
In DNS Manager, expand Forward Lookup Zones, and then click Contoso.com.
4.
Right-click Contoso.com, and then click New Host (A or AAAA).
5.
In the New Host dialog box, in the Name box, type mysites, in the IP address box, type
6.
7.
In the New Host dialog box, click Done.
Task 2: Create an application pool service account for the My Sites web application
1.
2.
3.
4.
In the Create User dialog box, in the Full name box, type My Sites Application Pool.
5.
In the User UPN logon box, type MySitesAppPool, verify that the User SamAccountName logon
6.
7.

1.
2.
3.
4.
5.
6.
On the Register Managed Account page, in the User name box, type CONTOSO\MySitesAppPool,
in the Password box, type Pa$$w0rd, and then click OK.
Task 4: Create and configure a new web application to host My Sites

1.
2.
3.
4.
In the Create New Web Application dialog box, under IIS Web Site, in the Name box, type
MySites - 80.
5.
6.
In the Host Header box, type mysites.contoso.com.
7.
Under Application Pool, in the Application pool name box, type SharePointMySites - 80.
8.
In the Configurable list, click CONTOSO\MySitesAppPool, and then click OK.
9.
10. Click MySites - 80, and then on the ribbon, click Managed Paths.
L12-6
11. In the Define Managed Paths dialog box, under Add a New Path, in the Path box, type personal.
12. In the Type list, ensure Wildcard inclusion is selected, click Add Path, and then click OK.
Task 5: Create a My Site host site collection

1.
2.
3.
http://mysites.contoso.com is selected. If it is not currently selected, click the current web
application, click Change Web Application, and then click MySites - 80.
4.
Under Title and Description, in the Title box, type MySite Host.
5.
Under Web Site Address, in the URL list, click /.
6.
Under Template Selection, on the Enterprise tab, click My Site Host.
7.
8.
Task 6: Enable self-service site creation for the My Sites host web application
1.
On the Web Applications Management page, click MySites - 80, and then on the ribbon, click
Self-Service Site Creation.
2.
In the Self-Service Site Creation Management dialog box, under Site Collections, click On, and
then click OK.
Task 7: Configure My Site settings for the User Profile Service application instance
1.
2.
applications.
3.
4.
On the Manage Profile Service page, under My Site Settings, click Setup My Sites.
5.
On the My Site Settings page, in the My Site Host Location box, type
http://mysites.contoso.com, and then click OK.
Task 8: Enable the User Profile Service Application - Activity Feed Job timer job
1.
Under Central Administration, click Monitoring.
2.
On the Monitoring page, under Timer Jobs, click Review job definitions.

L12-7
3.
On the Job Definitions page, click Contoso UPSA - Activity Feed Job.
4.
On the Edit Timer Job page, if the timer job is disabled, click Enable (if the timer job is already
enabled, the page will contain a Disable button instead of an Enable button. If the job is already
enabled, click OK).
Task 9: Test My Site creation by using a non-administrative user account

1.
2.
3.
4.
In the Windows Security dialog box, in the User name box, type jim, in the Password box, type
5.
On the SharePoint site, click Sites.
6.
7.
In the Get the most out of SharePoint dialog box, click OK.
Results: After completing this exercise, you should have configured My Sites and tested My Site creation
for non-administrative users.
Exercise 2: Configuring Audiences

Task 1: Create and configure a new audience for the sales team
1.
2.
3.
applications.
4.
5.
On the Manage Profile Service page, under People, click Manage Audiences.
6.
7.
On the Create Audience page, in the Name box, type Sales Audience, in the Owner box, type
8.
On the Add Audience Rule page, in the Operator list, click Member Of, in the Value box, type
Sales, and then click OK.
9.
On the View Audience Properties page, click Compile audience.
Task 2: Create and configure a new audience for the finance team
1.
2.
applications.
3.
4.
On the Manage Profile Service page, under People, click Manage Audiences.
5.
6.
On the Create Audience page, in the Name box, type Finance Audience, in the Owner box type
7.
On the Add Audience Rule page, in the Operator list, click Member Of, in the Value box type
Finance, and then click OK.
8.
On the View Audience Properties page, click Compile audience.
Task 3: Create a compilation schedule

1.
2.
applications.
3.
4.
On the Manage Profile Service page, under People, click Schedule Audience Compilation.
5.
On the Specify Compilation Schedule page, ensure Enable scheduling is selected.
6.
In the Start at list, ensure 1:00 AM is selected, click Every day, and then click OK.
7.
Task 4: Enable audience targeting for an announcements list
L12-8
1.
2.
3.
4.
On the SharePoint site, in the current navigation, click Announcements.
5.
On the Announcements page, on the ribbon, on the LIST tab, click List Settings.
6.
On the List Settings page, click Audience targeting settings.
7.
On the Modify List Audience Targeting Settings page, select Enable audience targeting, and
then click OK.
Task 5: Create an announcement that targets the Sales audience

1.
On the SharePoint site, in the current navigation, click Announcements.
2.
On the Announcements page, click new announcement.
3.
On the New Item page, in the Title box, type Sales Announcement.
4.
In the Body box, type This is a sales announcement.
5.
In the Target Audiences box, type Sales Audience, and then click Save.

L12-9
Task 6: Create an announcement that targets the Finance audience

1.
On the Announcements page, click new announcement.
2.
On the New Item page, in the Title box, type Finance Announcement.
3.
In the Body box, type This is a finance announcement.
4.
In the Target Audiences box, type Finance Audience, and then click Save.
5.
Task 7: Test the audiences

1.
2.
3.
4.
On the SharePoint site, verify that the Finance Announcement announcement appears on the
home page, but the Sales Announcement announcement does not.
Results: After completing this exercise, you should have created audiences and configured audience
targeting.

L13-1
Module 13: Configuring Enterprise Search

Exercise 1: Configuring the Search Service Application
Task 1: Create service accounts for the search service
1.
2.
3.
4.
Log on to the 20331B-NYC-DC-13 virtual machine as Contoso\Administrator with the password

Pa$$w0rd.
5.
6.
In the left navigation pane, click contoso (local).
7.
In the center pane, right-click Users, point to New, and then click User.
8.
In the Create User dialog box, in the Full name text box, type SPSearch.
9.
In the User UPN logon text box, type spsearch.
10. In the Password text box, type Pa$$w0rd.

11. In the Confirm password text box, type Pa$$w0rd.
12. Under Password options, select Other password options, and then select Password never expires.
13. Click OK.
14. In the center pane, right-click Users, point to New, and then click User.
15. In the Create User dialog box, in the Full name text box, type SPSearchAdmin.
16. In the User UPN logon text box, type spsearchadmin.
20. Click OK.
22. In the Create User dialog box, in the Full name text box, type SPSearchQuery.
23. In the User UPN logon text box, type spsearchquery.
27. Click OK.
29. In the Create User dialog box, in the Full name text box, type SPContentAccess.
30. In the User UPN logon text box, type spcontentaccess.
L13-2
34. Click OK.
Task 2: Register the service accounts as managed accounts

1.

Pa$$w0rd.
2.
3.
4.
In the Windows PowerShell Credential Re dialog box, in the User name text box, type
CONTOSO\SPSearch.
5.
In the Password text box, type Pa$$w0rd, and then press Enter.
6.
7.
In the Windows PowerShell Credential Re dialog box, in the User name text box, type
CONTOSO\SPSearchAdmin.
8.
In the Password text box, type Pa$$w0rd, and then press Enter.
9.
10. In the Windows PowerShell Credential Re dialog box, in the User name text box, type
CONTOSO\SPSearchQuery.
11. In the Password text box, type Pa$$w0rd, and then press Enter.
12. Close the SharePoint 2013 Management Shell window.
Task 3: Provision a Search Service application instance

1.
2.
3.
On the ribbon, on the New menu, click Search Service Application.
4.
In the Create New Search Service Application dialog box, in the Service Application name text
box, type Contoso Search.
5.
In the Search Service Account drop-down list, click CONTOSO\SPSearch.
6.
In the Application Pool for Search Admin Web Service section, ensure Create new application
pool is selected.
7.
In the Application pool name text box, type SharePointSearchAdmin.

L13-3
8.
Under Select a security account for this application pool, in the Configurable drop-down list,
click CONTOSO\SPSearchAdmin.
9.
In the Application Pool for Search Query and Site Settings Web Service section, ensure Create
new application pool is selected.
10. In the Application pool name text box, type SharePointSearchQuery.
11. Under Select a security account for this application pool, in the Configurable drop-down list,
click CONTOSO\SPSearchQuery.
12. Click OK.
13. Verify that the Manage Search Topology dialog box displays the message The Search Service
Application Contoso Search was created successfully, and then click OK.
14. On the Manage Service Applications page, verify that the search configuration process has created
the following three service applications:
o
A Search service application.
A Search Administration Web Service service application.
A Usage and Health Data Collection service application.
Task 4: Configure the default content access account

1.
On the Manage Service Applications page, in the list of service applications, select Contoso Search.
2.
On the ribbon, click Manage.
3.
On the Contoso Search: Search Administration page, in the Default content access account row,
click CONTOSO\SPSearch.
4.
In the Default Content Access Account dialog box, in the Account text box, type
CONTOSO\SPContentAccess.
5.
In the Password text box, type Pa$$w0rd.
6.
In the Confirm Password text box, type Pa$$w0rd, and then click OK.
Results: After completing this exercise, you should have created and configured a new Search service
Exercise 2: Configuring a File Share Content Source

Task 1: Create a new content source
L13-4
1.

2.
3.
4.
On the list of service applications, select the Contoso Search row.
5.
6.
On the Contoso Search: Search Administration page, on the Quick Launch navigation menu, click
Content Sources.
7.
On the Contoso Search: Manage Content Sources page, click New Content Source.
8.
On the Contoso Search: Add Content Source page, in the Name text box, type IT File Share.
9.
In the Content Source Type section, select File Shares.
10. In the Start Addresses section, in the text box, type \\NYC-DB1\ITShare.
11. Under Crawl Settings, ensure Crawl the folder and all subfolders of each start address is
selected.
12. In the Crawl Schedules section, under Incremental Crawl, click Create schedule.
13. In the Manage Schedules dialog box, in the Type section, ensure Daily is selected.
14. In the Settings section, in the Starting time drop-down list, click 3:00 AM, and then click OK.
15. Under Full Crawl, click Create schedule.
16. In the Manage Schedules dialog box, in the Type section, select Weekly.
17. In the Settings section, select Saturday.
18. In the Starting time drop-down list, click 2:00 AM, and then click OK.
19. On the Contoso Search: Add Content Source page, click OK.
Task 2: Grant access to the audit logs

1.
Switch to the 20331B-NYC-DB-13 virtual machine and log on as CONTOSO\Administrator with the
password Pa$$w0rd.
2.
On the Start screen, type Edit Group Policy, click Settings, and then press Enter.
3.
In the Local Group Policy Editor window, under Computer Configuration, expand Windows
Settings, expand Security Settings, expand Local Policies, and then click User Rights Assignment.
4.
In the list of policies, double-click Manage auditing and security log.
5.
On the Manage auditing and security log Properties dialog, click Add User or Group.
6.
Type CONTOSO\SPContentAccess, click Check Names, and then click OK.
7.
On the Manage auditing and security log Properties dialog, click OK.
8.
Close the Local Group Policy Editor window.

L13-5
Task 3: Configure permissions on the file share

1.
On the 20331B-NYC-DB-13 virtual machine, on the Desktop, open a File Explorer window and browse
to the E: drive.
2.
Right-click ITShare, and then click Properties.
3.
In the ITShare Properties dialog box, on the Security tab, click Edit.
4.
In the Permissions for ITShare dialog box, click Add.
5.
In the Enter the object names to select text box, type [email protected], click Check
Names, and then click OK.
6.
In the Permissions for ITShare dialog box, click OK.
7.
In the ITShare Properties dialog, click OK.
Task 4: Run a full crawl

1.
2.
3.
4.
In the list of service applications, select Contoso Search, and then on the ribbon, click Manage.
5.
Content Sources.
6.
On the IT File Share drop-down menu, click Start Full Crawl.
7.
8.
Click Refresh periodically until the Status column shows Idle.

Note: This may take two to three minutes.
9.
After the crawl completes, on the Quick Launch navigation menu, click Crawl Log.
10. Verify that the crawl completed without errors.
Results: After completing this exercise, you should have configured a content source for a network file
share.
Exercise 3: Configuring a Local SharePoint Content Source

Task 1: Configure the content source
1.

2.
3.
4.
On the list of service applications, select the Contoso Search row.
L13-6
5.
6.
Content Sources.
7.
On the Local SharePoint sites drop-down menu, click Start Full Crawl.
8.
9.
On the Contoso Search: Manage Content Sources page, click Local SharePoint sites.
10. On the Contoso Search: Edit Content Source page, under Crawl Schedules, select Enable
Continuous Crawls.
11. Under Full Crawl, click Create schedule.
12. In the Manage Schedules dialog box, in the Type section, select Weekly.
13. In the Settings section, select Sunday.
14. In the Starting time drop-down list, click 2:00 AM, and then click OK.
15. On the Contoso Search: Edit Content Source page, click OK.
16. On the Contoso Search: Manage Content Sources page, verify that the Local SharePoint sites
content source displays the status Crawling Continuous.
17. Click Refresh periodically until the Current crawl duration column is empty.
Note: This may take several minutes.
18. After the crawl completes, on the Quick Launch navigation menu, click Crawl Log.
19. Verify that the crawl completed without errors.
Results: After completing this exercise, you should have configured a content source for local SharePoint
sites.
Exercise 4: Creating a Search Center

Task 1: Create a new managed path
1.
On the Central Administration home page, under Application Management, click Manage web
applications.
2.
In the list of web applications, select SharePoint sharepoint.contoso.com80.
3.
On the ribbon, in the Manage group, click Managed Paths.
4.
In the Define Managed Paths dialog box, in the Path text box, type search.
5.
On the Type drop-down menu, click Explicit inclusion.
6.
Click Add Path, and then click OK.

L13-7
Task 2: Create a Search Center site collection

1.
On the Quick Launch navigation menu, click Application Management.
2.
Under Site Collections, click Create site collections.
3.
On the Create Site Collection page, under Web Application, ensure

http://sharepoint.contoso.com/ is selected.
4.
In the Title text box, type Search Center.
5.
In the Description text box, type Search results from across the Contoso enterprise.
6.
Under URL, on the drop-down menu, click /search.
7.
Under Select a template, on the Enterprise tab, select Enterprise Search Center.
8.
Under Primary Site Collection Administrator, in the User name text box, type
9.
Task 3: Test search functionality

1.
In the Internet Explorer address bar, type http://sharepoint.contoso.com/search, and then press
Enter.
2.
If you are prompted for credentials, log in as CONTOSO\Administrator with password Pa$$w0rd.
3.
In the search box, type How do I connect to a printer, and then press Enter.
4.
Verify that the search returns a link to the FAQs.docx file in the file share that you configured.
5.
In the search box, type Password policy, and then press Enter.
6.
Verify that the search returns a link to the IT Policies and Procedures.docx file in the file share you
configured.
7.
In the search box, type Fabrikam contacts, and then press Enter.
8.
Verify that the search returns a link to the Customer Contacts list on the local SharePoint site.
Results: After completing this exercise, you should have created a search center and tested your content
source configuration.

Exercise 1: Optimizing Search Results
Task 1: Configure a result source
L13-8
1.

Pa$$w0rd.
2.
3.
In the Internet Explorer address bar, type http://sharepoint.contoso.com/search.
4.
Pa$$w0rd.
5.
6.
On the Site Settings page, under Site Collection Administration, click Search Result Sources.
7.
On the Manage Result Sources page, click New Result Source.
8.
On the Add Result Source page, in the Name text box, type IT Team Fileshare.
9.
In the Description text box, type Files from the IT team network share.
10. In the Query Transform text box, type (or build) the following query transform:
{searchTerms} ContentSource="IT File Share"
11. Click Save.
Task 2: Configure a query rule

1.
2.
On the Site Settings page, under Site Collection Administration, click Search Query Rules.
3.
On the Manage Query Rules page, on the Select a Result Source drop-down menu, click IT Team
Fileshare.
4.
Click New Query Rule.
5.
In the Add Query Rule dialog box, in the Rule name text box, type IT Policies.
6.
Under Query Conditions, on the drop-down menu, click Advanced Query Text Match.
7.
Under Query Conditions, select Query contains one of these phrases (semi-colon separated),
and then in the text box, type policy;password;acceptable
use;guidelines;requisitions;hardware;software.
8.
Select the following options:
9.
Entire query matches exactly
Start of query matches, but not entire query
End of query matches, but not entire query
Under Actions, click Add Promoted Result.
10. In the Add Promoted Result dialog box, in the Title text box, type IT Policies and Procedures.
11. In the URL text box, type file://172.16.1.20/ITShare/IT Policies and Procedures.docx.

L13-9
12. In the Description text box, type This document provides definitive guidance on all IT policies
and procedures at Contoso.
13. Click Save.
14. On the Add Query Rule page, click Save.
Results: After completing this exercise, you should have created a result source and a query rule.
Exercise 2: Customizing the Search Experience

Task 1: Create a new search results page
1.
In the Internet Explorer address bar, type http://sharepoint.contoso.com/search and then press
Enter.
2.
Pa$$w0rd.
3.
On the Settings menu, click Add a page.
4.
In the Add a page dialog box, type itresults, and then click Create.
5.
On the itresults.aspx page, on the Search Results Web Part, on the drop-down menu, click Edit
Web Part.
6.
On the Search Results configuration pane, click Change query.
7.
In the Select a query drop-down list, click IT Team Fileshare (Site Collection), and then click OK.
8.
On the Search Results configuration pane, click Apply.
9.
On the ribbon, click Check In.
10. In the Check In dialog box, type a comment, and then click Continue.
11. On the Not published yet banner at the top of the page, click Publish it.
Task 2: Add a new tab to the search results

1.
2.
On the Site Settings page, under Search, click Search Settings.
3.
In the Configure Search Navigation section, click Add Link.
4.
In the Navigation Link dialog box, in the Title text box, type IT.
5.
In the URL text box, delete any existing text, and then type /search/pages/itresults.aspx.
6.
In the Description text box, type Search results from the IT team, and then click OK.
7.
On the Search Settings page, click OK.
Task 3: Verify that searches behave as expected

1.
At the top of the Site Settings page, click Search Center.
2.
On the Search page, type Request new hardware, and then press Enter.
3.
Under the search box, click IT.
4.
Verify that the page displays the IT Policies and Procedures item as a promoted result.
L13-10
Results: After completing this exercise, you should have created and configured a search results page and
customized the search navigation settings.

L14-1
Module 14: Monitoring and Maintaining a SharePoint 2013

Environment
Lab A: Monitoring a SharePoint 2013

Deployment
Exercise 1: Configuring Usage and Health Data Collection
Task 1: Configure usage and health data collection
1.
2.
3.
4.

Pa$$w0rd.
5.
6.
Click Monitoring, click Configure usage and health data collection.
7.
On the Configure usage and health data collection page, in the Usage Data Collection section,
select the Enable usage data collection check box.
8.
In the Health Data Collection section, select the Enable health data collection check box, and then
click OK.
Results: After completing this exercise, you should have configured SharePoint to collect usage and
health data.
Exercise 2: Configuring SharePoint Diagnostic Logging

Task 1: Configure diagnostic logging
1.
On the Monitoring page, click Configure diagnostic logging.
2.
In the Event Throttling section, select the All Categories check box.
3.
In the Least critical event to report to the trace log list, click Verbose.
Note: It is not recommended to configure verbose-level trace logging in a production

environment.
4.
In the Event Log Flood Protection section, ensure Enable Event Log Flood Protection is selected.
5.
In the Trace Log section, select the Restrict Trace Log disk space usage check box.
6.
In the Maximum storage space for Trace Logs (GB) box, type 10, and then click OK.
Task 2: Review a log file

1.
On the taskbar, click File Explorer.
2.
Browse to the C:\Program Files\Common Files\microsoft shared\Web Server

Extensions\15\LOGS folder.
3.
Locate the most recently updated log file.
Note: ULS trace logs are saved with filenames in the format <machine name>-<date><time>.log.
4.
Open the log file, and observe the number of events that are logged in just a few seconds.
5.
Close the log, and then close the File Explorer window.
L14-2
Results: After completing this exercise, you should have configured the diagnostic logging settings for a
Exercise 3: Configuring Health Analyzer Rules

Task 1: Review Health Analyzer problems
1.
On the Monitoring page, click Review problems and solutions.
2.
On the Review problems and solutions page, click one of the reported problems.
3.
Observe the details of the problem, paying particular attention to the Explanation and the Remedy
fields.
4.
Click Close.
Task 2: Configure Health Analyzer rule definitions

1.
On the Central Administration website, click Monitoring, and then click Review rule definitions.
2.
On the Health Analyzer Rule Definitions page, review the four categories of rules:
o
Security
Performance
Configuration
Availability
Note: The list of rules is paged. Click the Next Page button, displayed as a right-pointing
arrow below the list, to see additional rules. The number of rules will vary according to which
services are configured.
3.
In the Availability category, click Some content databases are growing too large.
4.
On the ribbon, on the View tab, click Edit Item.

L14-3
5.
Observe that you can change the following properties of the rule:
o
Title
Scope
Schedule
Enabled
Repair Automatically
Version
Note: You cannot change the actions that the rule uses to perform its health analysis task.
The actions of the rule are determined by the code used to develop the rule.
6.
In the Schedule list, click Daily, and then click Save.
Task 3: Run a Health Analyzer rule

1.
On the Central Administration website, click Monitoring, and then click Review rule definitions.
2.
In the Configuration category, click One or more categories are configured with Verbose trace
logging.
3.
On the ribbon, on the View tab, click Run Now.
4.
Click Monitoring, and then click Review problems and solutions.
5.
On the Review problems and solutions page, notice that an item named One or more categories
are configured with Verbose trace logging has been added.
6.
On the Review problems and solutions page, click One or more categories are configured with
Verbose trace logging.
7.
Review the details of the problem.
Task 4: Repair a detected issue

1.
On the ribbon, on the View tab, click Repair Automatically.
2.
Click Reanalyze Now, and verify that the issue is resolved.
3.
On the Review problems and solutions page, click Close.
4.
Click Monitoring, and then click Configure diagnostic logging.
5.
In the Event Throttling section, expand several categories and subcategories, and verify that in each
case the Trace Level is set to Medium.
Results: After completing this exercise, you should have configured Health Analyzer rules and repaired
any detected issues.
Exercise 4: Reviewing Usage and Health Data

Task 1: Explore the logging database
1.

Pa$$w0rd.
2.
On the Start screen, type SQL Server Management Studio, and then press Enter.
3.
In the Connect to Server dialog box, click Connect.
4.
In the Object Explorer window, expand the Databases node.
5.
Expand the WSS_Logging node, and then expand Views.
6.
Observe the many different database views that collate usage data.
7.
Right-click dbo.TimerJobUsage, and then click Select Top 1000 Rows.
8.
Notice that the view contains data, but that the data is not in a particularly user-friendly format.
Task 2: Create a logging report using Microsoft Excel
L14-4
1.
2.
On the Start screen, type Excel, and then press Enter.
3.
If a Microsoft Office Activation Wizard dialog box appears, in the Microsoft Office Activation Wizard
dialog box, click Close.
4.
On the Excel start screen, click Blank workbook.
5.
On the Data tab, click Get External Data, click From Other Sources, and then click From SQL
Server.
6.
In the Data Connection Wizard dialog box, in the Server name box, type NYC-DB1, and then click
Next.
7.
On the Select Database and Table page, in the Select the database that contains the data you
want list, click WSS_Logging.
8.
In the list of tables, click TimerJobUsage, and then click Next.

Note: TimerJobUsage is actually a view instead of a table.
9.
On the Save Data Connection File and Finish page, in the Description box, type Connection to
the TimerJobUsage view in the WSS_Logging database, and then click Finish.
10. In the Import Data dialog box, click PivotTable Report, and then click OK.
11. On the PivotTable Fields pane, drag the JobTitle field into the Rows box.
12. Drag the MachineName and WebApplicationName fields into the Filters box.
13. Drag the Duration field from the field list to the Values box.
14. Use the PivotChart to explore the timer job usage data.
15. Close Excel and discard your changes.
Results: After completing this exercise, you should have used data from the SharePoint logging database
to generate a PivotTable Report in Excel.

L14-5

Exercise 1: Analyzing Network Traffic
Task 1: Configure network traffic capture
1.
2.
3.
On the Tools menu (displayed as a cog icon), click F12 developer tools.
4.
In the developer tools pane, on the Network tab, click Start capturing.
Task 2: Review the network traffic generated by a page request

1.
2.
If the Windows Security dialog box appears, in the User name box, type Contoso\Administrator,
and in the Password box, type Pa$$w0rd, and then click OK.
3.
After the page finishes loading, in the developer tools pane, click Stop capturing.
4.
Review the list of HTTP requests generated by the page loading process.
5.
Notice that images, CSS files, and JavaScript files are downloaded as individual resources, and that
you can view the download time for each resource.
6.
Select one of the requests, and then click Go to detailed view.
7.
Explore the data on each of the tabs, and then click Back to summary view.
8.
Close F12 Developer Tools, and then close Internet Explorer.
Results: After completing this exercise, you should have captured and analyzed the network traffic
generated by a SharePoint page request.
Exercise 2: Analyzing SharePoint Page Performance

Task 1: Enable the SharePoint Developer Dashboard
1.
2.
3.
4.
[Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On
5.
6.
Close the SharePoint 2013 Management Shell.
Task 2: Review SharePoint page load data
L14-6
1.
2.
3.
If the Windows Security dialog box appears, in the User name box, type Contoso\Administrator,
and in the Password box, type Pa$$w0rd, and then click OK.
4.
After the page finishes loading, click the Launch the Developer Dashboard icon at the upper right
of the page.
5.
After the Developer Dashboard page finishes loading, switch back to the original Internet Explorer
window.
6.
Note: Press CTRL-F to refresh from the server instead of from the browser cache.
7.
After the page finishes loading, switch back to the Developer Dashboard window.
8.
On the Requests tab, click Request

(GET:http://sharepoint.contoso.com:80/SitePages/Home.aspx).
9.
On the Server Info tab, review the general information associated with the request.
10. On the SQL tab, review the database calls associated with the request.
11. Review the information on the remaining tabs, and then close the Developer Dashboard window.
Results: After completing this exercise, you should have enabled the SharePoint Developer Dashboard
and reviewed SharePoint page load data.

20331B ENU TrainerHandbook

Uploaded by

Copyright:

Available Formats

20331B ENU TrainerHandbook

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

20331B ENU TrainerHandbook

Uploaded by

Copyright:

Available Formats

M I C R O S O F T

MCT USE ONLY. STUDENT USE PROHIBITED

Core Solutions of Microsoft SharePoint

MCT USE ONLY. STUDENT USE PROHIBITED

ii Core Solutions of Microsoft SharePoint Server 2013

Microsoft and the trademarks listed at

Product Number: 20331B

MCT USE ONLY. STUDENT USE PROHIBITED

MICROSOFT LICENSE TERMS

MCT USE ONLY. STUDENT USE PROHIBITED

a. If you are a Microsoft IT Academy Program Member:

MCT USE ONLY. STUDENT USE PROHIBITED

b. If you are a Microsoft Learning Competency Member:

MCT USE ONLY. STUDENT USE PROHIBITED

If you are a MPN Member:

d. If you are an End User:

MCT USE ONLY. STUDENT USE PROHIBITED

LICENSED CONTENT BASED ON PRE-RELEASE TECHNOLOGY. If the Licensed Contents subject

MCT USE ONLY. STUDENT USE PROHIBITED

modify or create a derivative work of any Licensed Content,

work around any technical limitations in the Licensed Content, or

MCT USE ONLY. STUDENT USE PROHIBITED

DISCLAIMER OF WARRANTY. THE LICENSED CONTENT IS LICENSED "AS-IS" AND "AS

This limitation applies to

LIMITATION DES DOMMAGES-INTRTS ET EXCLUSION DE RESPONSABILIT POUR LES

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

x Core Solutions of Microsoft SharePoint Server 2013

MCT USE ONLY. STUDENT USE PROHIBITED

Core Solutions of Microsoft SharePoint Server 2013

Jason Lee Content Developer

James Hamilton-Adams Content Developer

John Devaney Content Developer

Mike Sumsion Content Developer

Stephen Ryan Content Developer

Scott Jamison Technical Reviewer

Module 2: Designing an Information Architecture

Module 3: Designing a Logical Architecture

Module 4: Designing a Physical Architecture

Module 5: Installing and Configuring SharePoint Server 2013

Module 6: Creating Web Applications and Site Collections

MCT USE ONLY. STUDENT USE PROHIBITED

xii Core Solutions of Microsoft SharePoint Server 2013

Lab B: Creating and Configuring Site Collections

Module 7: Planning and Configuring Service Applications

Module 8: Managing Users and Permissions

Module 9: Configuring Authentication for SharePoint 2013

Module 10: Securing a SharePoint 2013 Deployment

Module 11: Managing Taxonomy

Module 12: Configuring User Profiles

Module 13: Configuring Enterprise Search

MCT USE ONLY. STUDENT USE PROHIBITED

Core Solutions of Microsoft SharePoint Server 2013

Lab B: Configuring the Search Experience

Module 14: Monitoring and Maintaining a SharePoint 2013 Environment

Lab Answer Keys

MCT USE ONLY. STUDENT USE PROHIBITED

xiv Core Solutions of Microsoft SharePoint Server 2013

MCT USE ONLY. STUDENT USE PROHIBITED