Chapter 1. Design SharePoint Infrastructure

The previous version of Microsoft SharePoint has often been discussed as if it were two distinct products: SharePoint 2013 and SharePoint Online. SharePoint 2013 provides traditional IT organizations with the option of either federating with SharePoint Online or adopting an exclusively on-premises stance, in which all servers and development efforts are kept within the boundaries of the server room. If the federated SharePoint Online option is enabled, additional “cloud first” functionality is available to the organization’s users.

As you prepare for the 70-339 exam, you’ll be challenged to instead consider SharePoint 2016 and SharePoint Online as a single product. Although your organization might initially choose to implement SharePoint by using only on-premises functionality or only in the cloud, it’s more likely that you will find yourself implementing fully hybrid environments of SharePoint before too long. Planning for the overall infrastructure in the near term will make the initial environment more scalable and robust.

This section reviews the taxonomical, navigational, and structural considerations that should be decided on prior to implementing your SharePoint environment.

The first site created within a site collection is known as a top-level site, and it often defines the navigational relationship with all its subsites and their subsites (children, grandchildren, and so on).

Creating sites within a single site allows for a fairly straightforward navigational structure that is easily configured. As you begin the process of adding subsites beneath the top-level site, the creation process offers the chance for you to add the newly created sites to the overall navigational structure and also to inherit the structure to the site you are creating. This so-called structural navigation allows the navigational component of SharePoint to be easily customized to a point as the organization changes and grows.

As this chapter focuses on intersite navigation taxonomy, this section concentrates on the global navigation section, although the current navigation section might be mentioned in a limited capacity.

As with any configuration, there are benefits and drawbacks. In this case, configuration requires little effort to set up on the front end and might be sufficient for a smaller organization, but is it suitable for a growing company? Basing navigation on the structure of the organization can end up being quite restrictive and inflexible.

Organizational navigation might be accurate when the site is first configured, but your organizational structure itself might change. Several factors can cause broken or incorrect links within a site, such as new or divested acquisitions that alter the SharePoint navigational structure. A sudden shift in this structure to accommodate organizational change can result in broken bookmarks or errant search results.

Deciding which items get promoted to the navigation requires some interaction with the respective business units. When you meet with these units, it is important to throw the rule book out: A large whiteboard, some sticky notes (to foster navigation activities), and an open forum are all that is necessary to foster a solid navigational design. Challenge the members of the group to act as normal business users visiting the site. Don’t be afraid to make mistakes. These requirements form only an initial understanding of how the site is to be used; navigation can be refined by using site metrics as time progresses.

The requirement is to capture a simple series of metadata elements (such as user name, office location, and phone number), and for each office to maintain its own version of the list. Within each office’s list, you could build simple list columns to capture each of these distinct pieces of metadata (also known as information types).

So far, so good—maintaining two distinct lists for two separate offices isn’t really that tough. Adding values to each list requires you to visit its site and office list to make changes. As the company begins to add sites (and more office sites and lists), maintenance of these list columns becomes more error prone and time consuming.

Site columns are similar to list columns, but they are hierarchical in nature. When a site column is instantiated on a particular site, that site and all its child sites inherit the site column and its properties, allowing you to maintain the column from a single location within the structure.

Figure 1-3 shows the inheritance of three site columns within a site hierarchy. This example is oversimplified, but you can see the inheritance of site columns based on where they were initially created.

Site columns are hierarchical, inherited from parent to child. After a site column is created, a list can be assigned to that column (along with its information type and all metadata). If the metadata associated with the information type changes (for instance, adding a new color choice), this change can be propagated throughout any list that had previously been assigned to that site column.

Both list columns and site columns are defined by the type of content they possess (also referred to as the column’s information type). Most of these information types are scoped to the particular list or site column, meaning that metadata contained within the column is available only to sites residing within that site collection.

As is the case with site columns, content types behave in a hierarchical fashion and are inherited from each parent site to its child in the same site collection, as shown in Figure 1-4.

After a content type is created, a list or library can be assigned to that content type. If the content type is then changed at a later time (for instance, a new retention policy stage or new site column is added), these changes can optionally be propagated throughout any list or library that had previously been assigned to that content type.

In this case, you might assign a core set of site columns to the Legal Document content type and then assign workflows, retention policies, and more site columns to the individual child content types (Contract, Will, and so on).

Site collections are automatically populated with a series of content types that are themselves composed of out-of-the-box (OOB) site columns. The number and type of content types provisioned depend on two different factors:

Site template The template you choose when provisioning a new site

Features The features you select to add to an existing SharePoint site

So far, we have a series of site columns that can inherit managed metadata, but the content type is still limited in application scope to the site collection. If you build multiple site collections for your implementation (and you should), you’ll need a mechanism to make metadata available beyond the site collection boundary without having to build the same information type over and over again in each new site collection. For that, we will use the Managed Metadata Service (MMS) and a concept known as the content type hub.

A content type hub is a site collection specifically configured to provide content types to other site collections. The individual content types are syndicated by the MMS; the process is fairly straightforward:

1. The MMS is configured to allow the content type hub to be the only source for centralized content type syndication.

2. The MMS connection is configured to consume content types from the hub’s content type gallery.

3. Content types are placed in the content type hub for syndication.

4. Content types are published by the Content Type Subscriber timer job on a regular basis (every hour by default) to all web applications that are connected to the MMS application.

Information provided via the use of external content types is reusable, mimicking the behavior of normal content types within a site or site collection. Users who interact with an external content type do not have to be aware of the underlying data type, connection type, or security present. External content types also allow for the creation of lists and data columns within SharePoint that function identically to their native SharePoint counterparts.

The information represented by external content types is provided by BCS and surfaced in SharePoint by specific Web Parts:

Business Data Actions Displays a list of actions associated with an entity defined in BCS (for example, an external list) and made available to a user, such as sending email or editing customer information

Business Data Connectivity Filter Filters the contents of a connected Business Data Web Part by using values from an entity

Business Data Item Displays the details of an entity instance (for example, an item) from a business application, such as a particular customer or order

Business Data Item Builder Creates a Business Data Item based on URL query string parameters, then provides the output to other Business Data Web Parts

Business Data List Displays a list of entity instances (for example, items) registered in BCS, such as displaying a list of customers or orders

Business Data Related List Displays a list of related entity instances from a business application, such as showing all orders related to a particular customer

External content types and item pickers are also available for use within SharePoint along with profile pages, which can display details about a particular item. If more functionality is desired than what is presented by the OOB tools, development by using external content types is available via the SharePoint and client object models, or by using Representational State Transfer (REST) URLs.

Adding keywords to a list item or document is fairly straightforward, but requires a bit of configuration prior to use. The basic configuration process requires the MMS connection to be configured as the default storage location for keywords. Once this is complete, the enterprise keywords site column can be added to content types.

To configure the default storage location:

1. Open Central Administration and select Application Management.

2. Under Service Applications, select Manage Service Applications.

3. Scroll down the list of service applications, and click the blank area next to Managed Metadata Service Connection.

4. On the ribbon, on the Service Applications tab, click the Properties icon.

5. On the Edit Managed Metadata Service Connection page, select the This Service Application Is The Default Storage Location For Keywords check box (see Figure 1-6).

Once keywords have been added by users in the enterprise, these values are reflected within the Managed Metadata term store. Note that keywords are located under the System, Keywords group; none of the specialized term sets within the System group enables you to build any sort of hierarchy.

Keywords that are regularly used by business users in the organization can be reviewed and moved into term sets; doing so enables the keyword to become centrally managed as a term and moved into appropriate term sets. In other words, the keyword effectively makes the transition from folksonomy to taxonomy.

To transform a keyword into a term, right-click it and select Move Keyword (see Figure 1-8).

A series of destinations appear; at this point, you can select a term set (see Figure 1-9). You can also decide whether this word can continue to be used as a distinct keyword outside of this term set.

The ability to define multiple names for the same items; for example, searching for “put a kettle on” will return search results that include the phrase “make a cup of tea”

The ability to use acronyms in search; searches for CEO will return results that include “chief executive officer”

The manner in which the thesaurus is created truly matters. Each entry in the thesaurus is comprised of a key, a synonym, and a language; each should also be contained in its own line. By using our previous examples and building entries in English, our entry would look something like Figure 1-10.

1. In Windows PowerShell, set a variable to the Search service application.

2. Import the thesaurus by using the Import-SPEnterpriseSearchThesaurus cmdlet.

Click here to view code image

$searchApp = Get-SPEnterpriseSearchServiceApplication
Import-SPEnterpriseSearchThesaurus -SearchApplication $searchApp -Filename
\16sp2016rc\powershell hesaurus.csv

Once the thesaurus file has been successfully imported, the console will report the message, “Dictionary imported successfully,” as shown in Figure 1-11.

Promoted Results do not use keywords as triggers, instead using the query rule functionality for this task. To be effective, SharePoint Farm Administrators, Site Collection Administrators, and Site Administrators all have a hand in optimizing search results. To this end, Promoted Results can be configured at the following levels:

Search application Scoped within the boundaries of the particular Search application

Site collection Scoped to a single site collection

Site Scoped to a single site

Adding a query rule requires only three steps: Select an appropriate search context, specify one or more query conditions, and then specify the resulting action.

To make crawled properties useful within SharePoint search, managed properties must be created and mapped to the crawled properties. Although this process can be done manually, the majority of the time, SharePoint can do the conversions for you.

Creating a managed property at the site collection level and adding it to search requires just a few steps. In this example, we will be adding a site column called Phase to the Documents library, then making sure that SharePoint search is picking up the contents of the column.

1. Create the Phase site column.

2. Assign the Phase site column to a document library.

3. Create or edit an item in the list, adding metadata in the column you just created, then start a search crawl to create and map a managed property to the crawled property.

4. Verify that the property was created and mapped.

The Search Schema page within Site Collection Administration shows all of the managed properties, but you need to view the mapping between crawled properties and managed properties. Select Crawled Properties.

In the Filters section of the page, enter Phase into the Crawled Properties text box, and then select the green arrow to filter the properties. You should now see the Property Name ows_q_TEXT_Phase (the crawled property) and the Mapped To Property of PhaseOWSTEXT (the managed property), as shown in Figure 1-12.

If you need to have a managed property be sortable or refinable, you will create and map it from Central Administration in the Search service application.

This functionality is dependent on Office Online Server, the successor to the Office Web Apps server, and will not function without Office Online Server configured in the SharePoint farm. The resource ID of a document (docID) is stored within the content database and assigned to the document. When a user selects a durable link to a document, Office Online Server looks up the document by docID and then renders the document.

Keyboard shortcuts allow you to do standard tasks without having to use the ribbon, by using shortcuts that seem familiar to Microsoft Office users (such as Alt+N to create a new document).

Multiple documents can now be uploaded by using the Upload command (Alt+U) in a document library.

File menus in SharePoint are now right-click enabled, allowing you to download, open, share, rename, delete, and more.

Quick previews of videos and images are now available by hovering over or clicking them.

SharePoint 2016 provides specific functionality designed to regulate the creation, interaction, and disposition of content. An information management policy is a set of rules that can be assigned to any given piece of content. These rules (also known as policy features) then define behaviors, such as the retention schedule, auditability, or markings (bar codes and labels) for a given piece of content.

There are four sets of policy features available in SharePoint Server 2016: retention, auditing, bar codes, and labels.

After a retention policy feature has been enabled in SharePoint, a retention stage must be added to describe how the item will be managed according to the information management policy. This retention stage requires two elements to be valid: an event and an action. A third element, recurrence, is utilized only when certain actions are selected.

Opening or downloading documents, viewing items in lists, or viewing item properties

Editing items

Checking out or checking in items

Moving or copying items to another location in the site

Deleting or restoring items

When enabled, this feature creates a unique identifier value for a document and then inserts a bar code image of that value in the document. Although the default bar codes are compliant with the Code 39 standard (ANSI/AIM BC1-1995, Code 39), you can use the policies object model to add other bar code providers.

1. In Site Settings, Site Collection Administration, select Content Type Policy Templates.

2. On the Policies page, click Create to build a new information management policy.

3. Enter a name and description for the policy, then add a policy statement that will appear to users when interacting with items subject to this policy.

4. Choose and configure the pertinent policy features as applicable.

Policy features can be associated with a site collection policy template; that policy template can be associated with a content type, list, or library.

Policy features can be associated directly with a content type; the content type can then be added to lists and libraries.

Policy features can be associated directly with a list or library.

Note the hierarchy in the three different applications of information management; the more direct the application of policy features, the more difficult the administration of the features would be across multiple libraries, lists, or sites. After the policy has been applied at a high level (for instance, the top of the site collection), all subordinate levels using the same content type must inherit all information management policies present.

Search enables DLP users to find sensitive information types based on patterns defined by a regular expression or a function, and also make use of keywords and checksums. Proximity ratings give the DLP user a confidence rating (85 percent, 75 percent, 65 percent, or 55 percent) in the type of information retrieved.

Sensitive information types might include content such as bank routing numbers, credit card numbers, identification card numbers, and passport numbers; there are more than 80 template types available overall, although only a subset of these is available by default in SharePoint 2016. These types are specified by templates and are activated by DLP search queries put in place via an enterprise eDiscovery Center. When configuring the query of a search, the scope can be configured to search everything in SharePoint or to narrow the scope to one or more site collections.

Each new DLP policy requires that you select a policy template, select the number of instances of sensitive information that triggers an event, and then send an incident report when new content is saved or edited. Optionally, the user can be notified via a policy tip when their content contains sensitive information, and this content can also be blocked (but potentially overridden by the user).

Although many sensitive information types are accounted for OOB in SharePoint 2016, it’s possible to extend this functionality via Document Fingerprinting. Document Fingerprinting allows you to convert business documents (contracts, intellectual property, and other documents) into sensitive information types.

As we look to a hybrid installation of SharePoint 2016, we find that DLP is extensible in Office 365. If you have a predefined, text-based document template that you want to turn into a sensitive information type, Document Fingerprinting can be used to prevent the transmission of that document outbound, by using Information Rights Management (IRM).

IRM also permits users in the organization to configure item-level encryption via Information Rights Management Services, both on-premises and in the cloud. This level of content control maintains the governance requirements of the organization and prevents sensitive information from being made available to external users.

Earlier in this chapter, we defined the relationship between sites and site collections. A site is the most granular element in a given taxonomy and is formed from a combination of lists and libraries. Sites are functionally, navigationally, and administratively grouped together, into one or more site collections.

Within a site collection, moving a subsite around is fairly straightforward, requiring only that the Publishing Infrastructure feature be enabled:

1. Open Site Settings, Site Administration, Content And Structure.

2. Next to the site you want to move, click the drop-down arrow and then select Move, as shown in Figure 1-13.

3. Choose a destination site and click OK.

Moving sites between site collections is another story. Sites within a site collection share administrative groups, content types, permissions, policies, and other items, which are provided only within that site collection. Although it’s technically possible to copy a site to a different site collection by using the Export-SPWeb and Import-SPWeb PowerShell cmdlets, doing so does not make the newly copied site a full-fidelity copy of the original. Some permission and document settings are copied over, but other components (such as workflows) will not be transferred.

As their SharePoint implementations grow in size, most large organizations tend to focus on building multiple site collections rather than implementing fewer site collections with more sites and subsites. The problem then becomes one of navigation, which is addressed via a combination of two navigation types: path-based and metadata-based.

Explicit managed paths enable two site collections to be put into the same URL path. For instance, if you had a site collection at http://your.url.com/, you could create an explicit managed path (for example, /yoursite) to store another site collection at http://your.url.com/yoursite.

Wildcard managed paths enable one site collection to be the “implied” parent of several site collections. Doing so requires two things:

All site collections are nested under a path that itself is not a site.

All site collections in the wildcard are at the same URL level.

If you had a site collection at http://your.url.com/, you could build a wildcard managed path (/projects) to contain all your projects, each in its own site collection. So the projects would be located at http://your.url.com/projects/project1, /project2, /project3, and so on. If a user decided, however, to navigate directly to http://your.url.com/projects, there would be a problem because there is no site at that level, only the wildcard managed path.

Using the MMS, a navigational structure can be generated on a fairly dynamic basis, tying multiple sites and site collections together into an organized (and exceptionally flexible) structure. It should be noted that the navigational structure is generated on a per-site collection basis, with every site collection setting up a term set for its own use.

Managed navigation is dependent on one or more term sets, which are nothing more than a grouping of terms within the term store. Each term set defines a navigational structure, and multiple navigational structures can be utilized, even within a single site collection (if desired).

Within a site, global and current navigation can each use a term set for navigation. Note that global and current navigation cannot use two separate term sets—only a single term set can be specified on the navigation settings page of a site. The individual terms can be set to show in global navigation, current navigation, or both.

As discussed previously, MMS encompasses two distinct groupings of metadata: taxonomy and folksonomy.

Taxonomy The more formalized of the two groupings, taxonomy is hierarchical and deliberate in nature and includes terms and term sets.

Folksonomy The more casual of the two groupings, folksonomy imparts items with metadata by using tags or keywords, generated by individual users; no hierarchy can be implied or defined.

Term sets can have a status of either open or closed. An open term set enables anyone to contribute a new term; a closed term set enables only contributors and owners to add a new term.

Does everyone in the enterprise need access to a particular term?

Is the term specific in scope?

Who should be managing the term set?

What is the desired “footprint” of the term set?

A SharePoint MMS application is associated to a web application via the service application proxy. Terms provided via the proxy can be assigned to items within the desired SharePoint web application; the only consideration that must be made is one of scope.

Term sets are assigned by way of the Term Set Management Tool, which can be used at two distinct levels, local and global:

Local term sets are scoped to a single site collection and are created via the Term Set Management Tool in Site Collection Administration.

Global term sets are scoped to an MMS and are created via the Term Set Management Tool in Central Administration.

Working with an enterprise librarian or design team, it is quite preferable to involve this group of term set designers in planning simply because they have firsthand knowledge of the products and processes that are pertinent to their segment of the business.

Successfully implementing a term set involves five core activities: identifying each term set, identifying a term set owner, designing term set groups, defining the term sets themselves, and creating the term sets.

Custom columns, particularly those that enable the selection of one or more values (such as choice fields)

Words or phrases that are being regularly used to tag an item (from folksonomy to taxonomy)

Metadata that users often use to sort or filter items in a list or library

Acronyms or abbreviations for a function or product

Items that are, by definition, hierarchical in nature (for example, inventories)

Items that probably should not be included in a term set might include:

Items that have column metadata fields that have already been provided with the SharePoint framework (built-in columns)

Boolean (yes or no) values

Items that might have different values in different segments of a business

Items that have no well-defined values

In more formal term sets (global term sets, in particular), the term set owner is often not a single individual but a small team of people who are responsible for the overall correctness of the term set.

What terms belong in any given term set?

How are terms organized with a term set?

Who are the designated contributors for a given term set?

Farm administrators and designated term store administrators have the ability to define term sets at the MMS instance level. To begin using the Term Store Management Tool, these users can select the Term Store Management Tool from within an MMS associated with the SharePoint farm itself.

Starting with Office 2010, Open Document Format (ODF) documents (.odt, .ods, and so on) could be viewed and edited in the Office client; SharePoint also supported the storage of these documents, but they could not be made available as a template in a single library or used in a content type. This is remedied in SharePoint 2016, which now allows users to generate documents based on these templates in a library.

In a hybrid configuration, a user visiting a SharePoint site is presented the opportunity to interact with both on-premises and cloud-based functionality. By using a touch-enabled interface in this configuration, a user can select to browse sites, subsites, and content right alongside apps such as Delve and OneDrive for Business. This mobile view on a device can also be switched into a full web view as would be seen from a desktop computer.

If you build a basic SharePoint farm, activate the default service applications by using the OOB Farm Configuration Wizard, and then build a site collection by using the defaults, you would see from IIS Manager that several application pools, even more web applications, and a few SharePoint-specific websites have already been created (see Figure 1-14).

Looking at Figure 1-14, you can see that there is a SharePoint – tailspintoys.com80 application pool. Filtering on this pool (by right-clicking the application pool and selecting View Applications), you can see that this application pool hosts a single root application (see Figure 1-15).

There is also another application pool listed that hosts a different web application, which also provides services to the SharePoint – tailspintoys.com80 site. If you filter instead on SecurityTokenServiceApplicationPool, you can see that it is linked to the SharePoint – tailspintoys.com80 site and to the SharePoint Central Administration v4 and SharePoint Web Services sites (see Figure 1-16).

Grouping web applications that run with the same configuration settings

Isolating web applications that require unique configuration settings

Providing security by running a particular group of websites under a closely monitored service account for auditing purposes

Resource isolation

To prevent an outage of the entire IIS application based on one or more misbehaving or failed web applications

For Internet service providers (ISPs) to separate application pools based on customer resource needs

Before adding a new web application, consider using Performance Monitor (Perfmon.exe) to get a baseline of existing RAM usage. Monitoring a SharePoint environment is a topic that is covered in Chapter 7, “Troubleshooting and monitoring.”

Determining the purpose of a web application before it is implemented guides the direction of its configuration. Defining this purpose can be as easy as developing a set of questions such as the following:

What group of users does this application serve (intranet, extranet, Internet)?

How are users expected to authenticate?

What type of navigation do users expect when they visit the site or site collections in this web application?

How will site collections be created? There are two distinct choices: host-header site collections or path-based site collections, both of which affect web application design, and are discussed later in this chapter.

Windows authentication Integrated Windows authentication (NTLM or Kerberos)

Basic authentication Windows user name and password combination (encoded but not encrypted; password sent in clear text)

Forms-based authentication Using the ASP.NET membership and role provider

Trusted identity provider Secure Application Markup Language (SAML) token-based authentication

Each of these four authentication types uses claims-based authentication to a web application. Claims-based authentication is used for user, server-to-server, and app authentication; thus, it’s recommended for use with all web applications and zones of a SharePoint 2016 farm.

Classic mode authentication is also available for a SharePoint 2016 web application, but is no longer supported and should not be used for any new user-facing web applications. If required, web applications can be configured to use classic mode (Windows classic) authentication via PowerShell. In a new SharePoint 2016 farm, the only place you should encounter this authentication type is the Central Administration web application.

Windows authentication (recommended)

SQL authentication

When a SharePoint database is mirrored, SharePoint must know not only the name or instance of the principal server (where the database read and write transactions are occurring) but also the name or instance of the mirror server (the read-only copy of the database). If the mirrored database is failed over, SharePoint then knows the location of the alternate name or instance.

Boundaries A boundary is an absolute limit, meaning that the value given cannot be exceeded in the current version of SharePoint. An example of this type of limit is the number of zones in a web application; there are always five: default, intranet, extranet, Internet, and custom.

Thresholds A threshold has an initial value set, meaning that the value can be modified to a maximum value (boundary). Before altering these values, consideration should be given to whether your specific infrastructure can accommodate the increased load that might be caused by this change.

Supported limits A supported limit for any particular configuration parameter is a set value based on testing conducted by Microsoft. Although you can exceed supported limits, you might encounter unexpected results; these results could come in the form of diminished performance or unexpected behavior in the farm.

500 content databases per farm (supported limit)

General content database size recommendations:

100 GB maximum recommended

200 GB supported limit for general usage scenarios

A supported limit of 4 TB per content database for archival content databases with very little read and write access (supported limit)

No explicit limit for content databases housing document center or record center sites

If you examine these limits for a moment, you might come to realize that an environment approaching these levels would be quite large. A farm containing 500 databases with an average content database size of 50 GB would place the SQL back-end storage requirement somewhere in the neighborhood of 25 TB.

Content databases in the range of 50 GB are quite common. Content database growth beyond this level, eventually exceeding the 100 GB limit, will cause a warning to be generated in the SharePoint Health Analyzer, stating “Some content databases are growing too large.” In fact, there are two SharePoint Health Analyzer rules related to database sizing. The first, “Database has large amounts of unused space,” is a daily check that reports databases with large amounts of free space (pregrowth); the second, “Some content databases are growing too large,” is an hourly check that reports on content databases exceeding 100 GB in size.

Before contemplating the site collection taxonomy, you might first want to consider the life cycle of site collections. Some site collections are fairly permanent, providing the structural backbone of your SharePoint environment; others might be quite temporary (a one-off collaborative site collection, for instance) and can be disposed of when no longer in use.

In an environment in which you, the SharePoint administrator, are responsible for managing growth, the initial goal is scalability. By scaling your SharePoint environment to multiple site collections, you begin to account for potential growth.

In Figure 1-17, an example content database is initially configured with five site collections:

1. Over time, one of the site collections begins to experience rapid growth and begins to cause the content database to drastically increase in size.

2. The SharePoint farm administrator recognizes this growth and moves the larger site collection into its own content database to manage growth.

After the content database is moved, its growth can be restricted by setting the maximum number of site collections in the database to 1.

The farm administrator would then oblige by generating a new web application for the HR group and assigning it the hr.yoursharepointname.com host header. Other business units would find out about the new URL and begin to have the same requirement; soon the farm administrator could have several web applications, one for each new business unit.

If you were to build a farm and give each business unit its own web application (simply to give it a distinct URL), you might find that your farm will quickly exceed published web application limits and start to exhaust resources, particularly on the front-end servers.

The Central Administration interface for creating new web applications does not provide a way to build new Host-Header Site Collection (HHSC)-based web applications. When the HHSC web application is created, a path-based root site collection should also be created. This site collection should not be available for use, nor should it have a template assigned.

Assuming that the domain name for your SharePoint farm is something like yoursharepointname.com, you should request that your administrators place a wildcard (*) entry in DNS and point it to the IP address of your web server. Any requests that are made to this domain will then be referred to SharePoint.

SharePoint 2016 improves this mechanism by allowing site collections to be created from a master copy of a site collection for an enabled template (for instance, SPSPORTAL#0 for a Collaboration Portal). The master copy is called a Site Master, and is used as the blueprint from which your new site collections are created.

The optimization for this process is that the Site Master is copied at the content database level, with all pertinent features automatically enabled and ready for use.

Intranet/Internet access Your users require access to the web application from inside your corporate network by using their regular user name and password credentials.

Extranet access You have partners that require access but you need to provide another authentication mechanism, such as offering Forms Authentication (a user name and password combination that you administer).

Internet access You have other partners that want to use their credentials or a trusted Identity Provider (Microsoft, Facebook, Google, and so on) account to access content.

There are five zones available in SharePoint: default, intranet, extranet, Internet, and custom. Although there is no functional difference (by default) between the zones, they provide a structure to configure access for these different user segments accessing the same web application. Each type of user can have a distinct URL and mechanism for accessing your corporate systems.

There are two ways to associate a web application with a zone.

Alternate access mappings Map internal URLs to public URLs, directing users to the appropriate URLs when interacting with SharePoint 2016 sites

Set-SPSiteUrl Used to add or change URL mappings for host-named site collections

When a new SharePoint web application is created, its URL is stored in the default zone. If claims authentication is to be added along with another authentication mechanism, some consideration should be given to adding claims authentication to the default zone so the same URL can be used both inside the network and from outside the network.

In SharePoint 2016, the optimal configuration expands on the traditional topology, adding servers to create a streamlined topology. In this topology, both system performance and resources are optimized because servers are compartmentalized into roles (based on the function they perform).

This compartmentalization is further reinforced by the MinRole concept. In this concept, servers are assigned one of six possible roles:

Front-end Serve user requests; optimized for low latency

Application Serve back-end requests; optimized for high throughput

Distributed cache Hosts only components required for a distributed cache

Search Hosts only components required for searching

Custom Hosts components that do not integrate with MinRole; the farm administrator has full control over which service instances can run on servers assigned to this role

Single-server farm Hosts all components required for a single SharePoint server to operate in a farm configuration; this configuration should be limited use

SharePoint 2013 was quite capable of expanding to meet enterprise needs; SharePoint 2016 is no different, allowing for multiple farm types that utilize MinRole server roles. These farms meet specific requirements when federated together:

Content Farm Requires the Front-end web, Application, and Distributed cache roles; Search and Custom roles are optional

Shared Services Farm Requires only the Application and Distributed cache roles; Search and Custom roles are optional

Search Farm Requires only the Search role; Custom roles are optional

MinRole and its effect on service topologies are covered later in this chapter in the “Define service topologies” section.

Creating a new Central Administration web application is the same as it was in SharePoint 2013: Log on to the server you want to host this web app, and run the New-SPCentralAdministration PowerShell command with the desired switches. If you previously built the first server in a farm but do not want it to host Central Administration, there is a new PowerShell command designed for this use: Remove-SPCentralAdministration.

Three storage architectures are supported within a SharePoint environment: direct-attached storage (DAS), storage area network (SAN), and network attached storage (NAS). DAS and SAN storage architectures are fully supported; NAS storage is supported only for content databases configured to use Remote BLOB Storage (RBS).

Each storage architecture has an associated set of hardware and administrative costs; the storage type you choose is often based on the hardware and administrative structure you have available within your enterprise.

The Fibre Channel connections between the storage and host are attached by using either twisted-pair copper wire or fiber-optic cables. A host connected to the SAN uses a host-based adapter to transfer small computer system interface (SCSI) commands to the storage by using the Fibre Channel Protocol (FCP) for transport.

SharePoint 2016 supports several types of disks:

Small computer system interface (SCSI)

Serial Advanced Technology Attachment (SATA)

Serial Attached SCSI (SAS)

Fibre Channel

Integrated drive electronics (IDE)

Solid-state drive (SSD)

Without going into on-disk caching, rotation speed, or other in-depth storage tuning discussions, you can pretty much break down this list in terms of newer, faster drive technologies (SSD, SAS, SATA, Fibre Channel) and older technologies (SCSI and IDE). Often, the type of drive you choose will just come down to the available interface types provided by your storage subsystem.

SharePoint 2016 supports all RAID types, but the recommendation for best performance characteristics is to implement RAID 1+0 (also known as RAID 10). This RAID type configures drives in a striped set of mirrored drives—the mirroring component provides fault tolerance, and the striped component maximizes performance. In such a system, multiple drives can sustain losses, but the RAID does not fail unless a mirror loses all its drives.

Although it is possible to configure an external load balancer to understand the specific behaviors required for a SharePoint environment, such solutions can have shortcomings:

Changes made at the load balancer level can have dramatic effects on the SharePoint farm, resulting in inconsistencies or outages.

Changes made within the SharePoint farm but not reflected in the load balancer configuration (such as Search crawler changes) can have a negative effect on performance.

For instance, consider a SharePoint farm that is serving both user requests and Search crawls at the same time. Enough Search requests might cause the SharePoint environment to have increased latency when serving user requests; such a situation could result in a perceived outage and irregular work stoppages.

Request management is a better mechanism for intelligent request routing and throttling, present in both SharePoint Server 2013 and 2016. Request management can be enabled on a per web application basis, enabling incoming requests to be evaluated against a set of rules to determine which Front-end server (if any) will respond.

Dedicated mode deployments are useful in larger environments and allow for the segmentation of request management activities away from the Front-end servers servicing the requests.

In an integrated mode deployment, request management is handled directly on the Front-end servers, meaning that any server running the SharePoint Foundation Web Application Service also has the Request Management service instance provisioned.

Interestingly enough, a single-server farm installation of SharePoint requires significantly more memory and resources on the individual server than would be required on each server in a distributed server installation. The reason for this requirement is rather straightforward: A single-server farm installation combines all required services for Front-end web, Application, Distributed cache, and Search onto a single server.

In such an environment, the SQL server serving as the data layer of the farm should meet at least the minimum requirements (4 GB of RAM for SQL 2014 and 2016).

The following requirements do not really address items such as the storage space required for the databases and any other services (such as Search indexes). The recommendation is to add a secondary drive for the storage of such information.

The basic requirements for a single-server SharePoint farm depend greatly on the SharePoint installation chosen and are shown in Table 1-1.

It is important to note that MinRole server roles must govern the majority of service assignments within a farm (see Table 1-3 for details).

The following topologies are by no means the only ones available, but they give guidance as a starting point for topology designs.

In SharePoint 2016, MinRole controls the assignment of services to a server based on its role in the farm. Although it might seem that you could follow the Front-end, Application, and Data server configuration, doing so would omit a key component, the distributed cache service; without this component, a farm is considered unsupported.

Thus, a minimal MinRole-compliant configuration of SharePoint will contain four tiers (Front-end, Application, Distributed cache, and Data), as shown in Figure 1-19.

There’s one component we haven’t yet considered: Search. The four-tier farm we’ve discussed does not incorporate any search services; we need to add one more server that holds the Search MinRole, moving us into a five-tier farm configuration (shown in Figure 1-20).

For a SharePoint content farm to be fully resilient using MinRole server roles (excluding SQL servers), you need a total of nine servers, arranged as shown in Figure 1-21.

Resiliency at the data layer is discussed in Chapter 3, when we discuss the AlwaysOn options available in SQL Server.

As a result, servers in the web and application tiers of a SharePoint farm ideally will have at least two distinct network interfaces: One handles user requests, routing traffic back and forth to users, and the other handles interserver connectivity, routing traffic back and forth between the SharePoint servers (Front-end, Application, Search, and Distributed cache tiers) and the SQL data tier.

SharePoint 2016 allows for highly available farms to be distributed or “stretched” if they meet the following criteria:

There is a highly consistent intrafarm latency of < 1 millisecond (ms) one way, 99.9 percent of the time over a period of 10 minutes. (Intrafarm latency is commonly defined as the latency between the front-end web servers and the database servers.)

The bandwidth speed must be at least 1 gigabit per second.

Obviously, transferring files this large into any content database should be done with an eye toward how they are to be used. Although content databases are no longer subject to the 200 GB supported limit, the fact remains that a site collection that has several hundred GB of storage will take quite a long time to back up and restore; the surface area for database corruption is also increased, making the scope of a failure potentially push both the Recovery Time Objective and Recovery Point Objective beyond organizational governance limits.

In SharePoint 2016, then, we are left with two different hosting models: SharePoint-hosted and Provider-hosted. The SharePoint-hosted Add-in model is centered around SharePoint components, including lists, pages, Web Parts, workflows, libraries, and more. In this model, Add-in parts and custom actions are deployed in the host web, and all other components are deployed to the Add-in web.

The Provider-hosted model builds on the SharePoint-hosted model, allowing the use of additional remote components such as web applications, services, or databases, hosted in a separate web stack. The stack chosen is located outside the SharePoint farm and does not have to necessarily even be on a Microsoft stack (for example, it can be supported on other web hosting frameworks such as LAMP, Python, and others).

When the prerequisite installer is run on a Windows Server 2012 or Windows Server 2016 server, it checks to see if a prerequisite component is installed. If the installer finds a prerequisite component, the individual component installation is skipped and the installer moves to the next item in the list.

Clicking Install Software Prerequisites immediately activates the SharePoint 2016 Products Preparation Tool, shown in Figure 1-23.

After you click Next and accept the license terms, the tool runs through the list of items to be installed, first configuring the Application server and Web server roles, and then proceeding with the installation of the other components.

The solution is to gather the components together into a centralized location and then install the prerequisites to each server as needed. This type of installation involves two separate actions:

Installing and configuring the Application Server role and Web Server (IIS) role to the new servers via Windows PowerShell (requires Windows Server 2012 R2 or Windows Server 2016 media)

Creating a set of installation switches to run with the Prerequisiteinstaller.exe tool, then downloading the components to a file share that is accessible by the new server

Each of these installations can be run individually, but they are most often batched together into an arguments file and run all at once.

After these steps are complete, the farm will be technically up and running, but it will require further configuration to meet user needs. Additionally, it probably won’t be configured to your specifications or those of your corporate IT department. For instance, running the Farm Configuration Wizard will create a series of content and service application databases. It is unlikely that the names of these databases will meet the naming convention requirements in your organization because SharePoint uses default database names that include a globally unique identifier (GUID) suffix.

Most enterprise installations require multiple servers in their SharePoint farm. The ability to reliably create, re-create, and duplicate server functionality in the farm requires you to find a better mechanism for installing and configuring SharePoint, a script.

Installation scripts can be broken down into three core segments:

1. Prerequisite installation and configuration (previously covered)

2. Farm creation and configuration of Central Administration and assignment of MinRole

3. Installing and configuring service applications (covered throughout this book)

In this section, you will review the core elements required to create and configure the farm via script, including both SQL and SharePoint configuration efforts.

This value can be set via the SQL Server Management Studio (SSMS) GUI, via a T-SQL script, or via PowerShell. The thing to remember about configuring MAXDOP in your farm PowerShell scripts is that neither your SharePoint setup account nor your SharePoint farm account should have this level of permission on the SQL instance. As a result, you will most likely need the SQL DBA to configure this value on your data tier before proceeding with the rest of the scripted actions.

A SharePoint Farm account will also need to be created, set up simply as a user in Active Directory; the SharePoint setup process will take care of assigning required permissions to the farm account as part of the installation.

The initial farm configuration can be broken down into three major sections: creating the farm, installing farm features and services, and creating the Central Administration web application. The only real difference between SharePoint 2013 and SharePoint 2016 farm creation from a scripting perspective is the addition of the LocalServerRole switch, which specifies the server role in the farm (MinRole).

Click here to view code image

psconfig.exe -cmd configdb -create -server <SqlServerName> -database <ConfigDbName>
-user <DOMAINFarmServiceAccount> -password <FarmServiceAccountPassword> -passphrase
<FarmPassphrase> -admincontentdatabase <AdminContentDbName> -localserverrole
<ServerRole> -cmd helpcollections -installall -cmd secureresources -cmd services
-install -cmd installfeatures -cmd adminvs -provision -port <PortNumber>
-windowsauthprovider onlyusentlm -cmd applicationcontent -install

In the preceding PSConfig command, notice that the installation assigns the role and then adds in modular sections like help collections, secure resources, and install features. This is similar to how the sections are added when creating the farm in PowerShell.

To begin the installation, open a SharePoint 2016 Management Shell window, running with administrative privileges. You will see a message that indicates “The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered,” as shown in Figure 1-25.

This warning indicates that there is currently no farm, which is created starting with the following script.

Click here to view code image

# Create the Configuration Database
# ServerRole can be any of the following:
# WebFrontEnd, Application, DistributedCache, Search, Custom, or SingleServerFarm
New-SPConfigurationDatabase -DatabaseServer <SqlServerName> -DatabaseName <ConfigDbName>
-FarmCredentials <FarmServiceAccountCreds> -Passphrase <FarmPassphrase>
-AdministrationContentDatabaseName <AdminContentDbName> -LocalServerRole <ServerRole>

Next, we must install the core components of the farm, including the help site collection files, resource security, available services, and all existing features.

Click here to view code image

# Install the Help Site Collection Files in the Current Farm
Install-SPHelpCollection -All
# Enforce Resource Security on the Local Server
Initialize-SPResourceSecurity
# Install and Provision Services on the Farm
Install-SPService
# Install Features from the Feature.xml file
Install-SPFeature -AllExistingFeatures

The last step in creating the initial farm is the creation of the Central Administration web application.

Click here to view code image

# Create Central Administration Web App
New-SPCentralAdministration -Port <caport> -WindowsAuthProvider "NTLM"
# Copy Shared Application Data to Existing Web Application Folders
Install-SPApplicationContent

Access Services 2010 is a backward-compatible service application to support the creation, editing, and updating of linked Access databases into a SharePoint Server farm; once created, these web databases can be accessed via an Internet browser, the Access 2010 client, or a linked HTML page.

Access Services is the current service application designed for the housing and presentation of Microsoft Access 2013 and 2016 databases. This functionality is available both on-premises and in the cloud (Office 365) via the use of Access apps.

When new servers must be added to the existing farm, these servers must match the current update level of the existing farm to join. Although it’s perfectly acceptable to install the binaries from the original media and then add each individual update, you might find this process labor-intensive and potentially error prone.

The solution, then, is to find a way to update the installation media itself. This process is called slipstreaming, and involves downloading each update and applying the update over the previous installation media. This media can then be used to create new servers that will join your SharePoint farm with no issues.

If you open your SharePoint installation media in Windows Explorer, you can see that there are several subdirectories present at the root directory. One of these subdirectories is called Updates, and this is where you will be extracting and applying your updates, cumulative updates, and service packs (see Figure 1-26).

After this directory has been populated with updates, it can be automatically installed by the SharePoint Products Configuration Wizard as part of the installation process.

To prepare the slipstream media on a network share called \<servername>SPInstall, you would do the following:

1. Copy the original SharePoint 2016 installation media to the SPInstall share.

2. Extract each update to the Updates folder in the SPInstall share, starting with the oldest update first. The update can be extracted by using the /extract switch (refer to the installation instructions for each update).

In the following examples, the German language pack will be installed. The language pack installer appears in Figure 1-27, in the destination language (German).

After the installation is complete, you are offered the opportunity to run the SharePoint Configuration Wizard (Figure 1-28).

After SCP functionality is correctly set up, any new SharePoint farm created in the domain will automatically register itself; the process of running the SharePoint Products Configuration Wizard causes a marker to be created and stored in the SCP container. This marker contains the address for the Application Discovery and Load Balancer Service (the Topology service application) for the individual farm, and is useful on multiple levels.

If you suspect that your environment might have many different SharePoint installs, you can use this functionality to begin building a working inventory of SharePoint 2010, 2013, and 2016 farms. If you have multiple domains that might contain SharePoint farms, you must configure the use of this marker in each domain to track these installations.

1. Run ADSIEdit; from the Action menu, connect to the default naming context of your domain as shown in Figure 1-29 (in this example, 16DC.rc.local).

2. Expand the domain that you want to connect to, then select CN=System.

3. Right-click in the white area of the details pane to open a shortcut menu. Select New, Object (see Figure 1-30).

4. Select the Container class in the Create Object box. In the Value box, type Microsoft SharePoint Products and then click Next. When you click Finish, your new Active Directory container should appear in the details pane (see Figure 1-31).

5. Assign permissions to the container, choosing the users you want to access the SCP container and assign them Write permissions. Alternately, you could select the Authenticated Users group and assign it Read and Write permissions (preferred).

To register an existing farm in the SCP container, either run the SharePoint Configuration Wizard or register the SharePoint farm in an SCP using Windows PowerShell. To create an SCP in Windows PowerShell (assuming you have the correct permissions), do the following:

1. Use Get-SPFarmConfig to see whether the farm is already registered (optional):

Click here to view code image

Get-SPFarmConfig -ServiceConnectionPoint

2. Use Set-SPFarmConfig to register the farm in the SCP container (the URL shown is the uniform resource identifier [URI] of the farm’s Topology service in our example):

Click here to view code image

Set-SPFarmConfig -ServiceConnectionPointBindingInformation
http://16SP2016RC:32844/Topology/topology.svc

To remove the SCP for your farm, use the -ServiceConnectionPointDelete option with the Set-SPFarmConfig cmdlet:

Click here to view code image

Set-SPFarmConfig -ServiceConnectionPointDelete

Click here to view code image

Get-SPFarmConfig -ServiceConnectionPoint

When considering the deployment of Office Online Server, you’ll need to account for three core functions: Previews and Online Viewing, Durable Links, and Excel Services.

Office Online Server also provides Online Viewers, which allow a user to view Word, Excel, and PowerPoint files that are stored in file shares and other websites. Using the URL http://<OfficeWebAppsServername>/op/generate.aspx, links can be generated for documents that have UNC or URL addresses.

When a user selects a link to a document, Office Online Server looks up the resource ID and returns the document to the user for presentation in Office Online Server Preview. If the document has previously been moved into a library to which the user has no permissions, the document will not be displayed, although the link is still valid.

This change in functionality means that additional planning is required to replace Excel Calculation Services functionality when moving content from SharePoint Server 2013 to SharePoint Server 2016. Some functionality present in Excel Calculation Services, such as trusted data providers, file locations, and data connection libraries, has been deprecated due to the change in architecture. PowerShell administration functions for Excel Services are no longer administered from within the SharePoint farm and are now applied from within the Office Online Server farm.

With this change in architecture, however, Excel Services is positioned as a modern platform capable of providing Web Parts in SharePoint while also adding current programmability features such as JavaScript Object Model (OM), User Defined Function Assemblies, Simple Object Access Protocol (SOAP), and Representational State Transfer (REST) protocol support.

Once the farm has been created, server-to-server authentication can be set up between it and SharePoint Server 2016.

As was the case with Office Web Apps Server, server instances (either physical or virtual) that run Office Online are resource intensive. This means:

Server applications such as Exchange, SharePoint, Skype for Business, or SQL should never be installed alongside Office Online Server.

Office Online Server will not run on servers that run Active Directory Domain Services (domain controllers).

Microsoft Office should never be installed on a server that is running Office Online Server.

Don’t install any services or roles that depend on the Web Server role (IIS) on ports 80, 443, or 809, as Office Online Server periodically removes web applications on these ports.

SharePoint Online does not provide a mechanism for creating new managed paths, either via the GUI or via PowerShell cmdlets. When migrating content from an on-premises SharePoint 2016 environment, /sites and /teams are the only wildcard managed paths available to store migrated site collections.

My Site URL Selecting the My Site URL requires the logged in admin to sign in to Office 365 as the global admin; the My Site URL will be automatically provided.

Select Audience For Hybrid Features The SharePoint admin can choose either to make the hybrid features available to everyone, or to limit the availability of hybrid features by using one or more audiences (useful for a phased deployment of hybrid features).

Select Hybrid Features By default, hybrid OneDrive and Sites features are not enabled; admins can choose to deploy OneDrive only or both OneDrive and Sites.

The deployment of Office Online will rely on a project structure, with topics such as these:

Determining deployment goals

Developing training guidelines and requirements

Inventorying the current environment

Making deployment decisions (such as product deployment order)

Analyzing and correcting issues that will prevent efficient deployment

Setting up the appropriate Office 365 services

Rolling out Office 365 functionality to users (phased deployment)

SharePoint 2016 farms

Exchange farms

Skype for Business

Office Online Server

SharePoint Online

Azure Active Directory

On-premises S2S authentication between two Microsoft servers does not require a third-party server. Server products such as SharePoint, Exchange, and Skype can issue and sign a security token and then communicate with other Microsoft servers.

When setting up S2S, OAuth is configured to use HTTPS by default. If you choose to use HTTP instead of HTTPS, you will need to do the following:

Allow the use of HTTP for outbound HTTP connections from Office Online Server

Allow the use of HTTP paths to store Office Data Connection files

Additionally, SharePoint Server 2016 hybrid configurations also require the following services to be running on your farm:

Managed Metadata Service (MMS) application

User Profile Service application

My Sites

Enterprise Search Search Center in SharePoint Online automatically includes results from your on-premises content. You can customize your Search Center in SharePoint Online, for example, by adding custom refiners.

Search verticals Search verticals narrow search results to a specific set of content, for example, to show only videos. If you currently use a search vertical in your Search Center in SharePoint Server, you have to re-create it in your Search Center in SharePoint Online.

Content metadata from your on-premises SharePoint 2016 implementation is securely encrypted as it’s transferred to the Search index in Office 365. Search itself is configured from Office 365, except for setting up content crawls, which you do in Central Administration on your SharePoint Server farm.

Storing the Search index fully in the cloud means that users always have the most current SharePoint Online search experience possible. From an administrative point of view, you no longer have to migrate the Search index as you upgrade your on-premises installation of SharePoint; additionally, you don’t have to worry about the overall size of your Search index, as it does not require any on-premises resources.

At its core, the configuration of cloud hybrid search is comprised of the following configuration steps:

1. Configure Office 365 for your SharePoint hybrid implementation.

2. Create a cloud Search service application in SharePoint Server 2016 by using the CreateCloudSSA.ps1 PowerShell script.

3. Connect the cloud Search service application to the Office 365 tenant by using the Onboard-CloudHybridSearch.ps1 PowerShell script.

4. Create (and then crawl) content sources.

Hybrid federated search can be configured in inbound, outbound, or bidirectional hybrid topologies. In an Outbound configuration, users receive hybrid results when searching from the SharePoint Server 2016 Search Center, whereas in the Inbound configuration, users receive hybrid results when searching from the SharePoint Online Search Center. Bidirectional hybrid is, of course, a combination of Inbound and Outbound search configurations. All of these configurations assume that you have already set up synchronization of Active Directory to the cloud and that you have previously established your server-to-server trust with Office 365.

Displaying hybrid federated search results in the SharePoint 2016 Search Center (Inbound) requires that the following procedures be completed:

A result source is created that defines how Search results are retrieved from SharePoint Online.

A query rule is created to turn on hybrid Search results in SharePoint Server 2016.

Displaying hybrid federated search results in the SharePoint Online Search Center (Outbound) requires that the following procedures be completed:

A result source is created that defines how Search results are retrieved from the on-premises deployment of SharePoint Server 2016.

A query rule is created to turn on hybrid Search results in SharePoint Online.

During activation, both of these features configure a server-to-server (OAuth/S2S) trust between SharePoint Server 2016 and Office 365. Hybrid Picker requires that the App Management, Subscription Settings, and User Profile Services are running and configured; additionally, the Search service application must be running and configured.

A series of prerequisites must be met prior to using the Hybrid Picker:

An on-premises SharePoint Server 2013 farm requires the September 2015 Public Update; no action is necessary for SharePoint Server 2016.

Ports 80 and 443 must be opened on the firewall for your on-premises configuration outbound to Office 365.

You must log in to a server in the on-premises SharePoint Server farm with an account that accesses Central Administration as a Farm Administrator; from the same server, you must also log in to Office 365 as an account that is a Global Administrator.

On-premises accounts being synchronized must have an email address, a Session Initiation Protocol (SIP) address, or a Simple Mail Transfer Protocol (SMTP) address.

In an exclusively on-premises implementation of OneDrive for Business, users are forced to log in via some mechanism to access their corporate storage. If this environment is available via a hybrid configuration, users can securely access their data from outside your corporate network. Information stored in this environment is still subject to governance settings that are configured from within SharePoint Server 2016.

Configuring OneDrive for Business allows you to configure Office 365 to host hybrid users’ profile information, and is available in both SharePoint 2013 and 2016. Profile information is also automatically made available within Delve.

Once the Extensible Hybrid App Launcher has been enabled, on-premises users of SharePoint Server 2016 can access apps such as Office 365 Delve and Video, and also access any custom Office 365 tiles. Additionally, any custom tiles pinned to the Office 365 app launcher will automatically appear in the on-premises SharePoint Server 2016 app launcher.

Keywords, synonyms, promoted results, and managed properties heavily influence Search results.

Durable links are a mechanism for linking documents that will survive a move or renaming action.

DLP queries allow users to discover sensitive content in a farm, and DLP policies allow for the automated management of sensitive information.

There are four claims-aware authentication types in SharePoint 2016: Windows authentication, Basic authentication, Forms-based authentication, and a Trusted identity provider. Classic mode authentication is not supported in SharePoint Server 2016.

A software boundary is an absolute limit that cannot be exceeded or changed, whereas a software threshold has an initial value set that can (if required) be expanded to the boundary limit, and a software limit is a configuration value that is set based on performance testing by Microsoft.

A site collection can be moved from one content database to another; a site cannot.

A MinRole-compliant farm can run on as few as one SharePoint server (Single-server server role), three SharePoint servers (one server in each of the Front-end, Application, and Distributed cache tiers), or four SharePoint servers (one server in each of the Front-end, Application, Distributed cache, and Search tiers). A fully resilient MinRole-compliant farm runs on a minimum of nine servers (two each in the Front-end, Application, and Search tiers with three servers in the Distributed cache tier).

The maximum degree of parallelism (SQL setting) for a SharePoint farm is 1.

Server-to-server authentication is a mechanism of establishing a trust between two server environments.

You are creating the first SharePoint farm at your company, and have been given guidance by your management to keep costs down. You are supporting a minimal number of users, but are supporting a large body of content that will need to be stored in SharePoint.

Answer the following questions for your manager:

1. How many servers need to be purchased (not including the data tier) to build the first production environment? What MinRole will be used?

2. How many servers need to be purchased to make the environment fully resilient (not including the data tier)? How many tiers will there need to be? What MinRoles will be used?

3. What sort of problems might you expect from an information topology standpoint?

1. To build the smallest possible farm, you will need a single server, configured with the Single-server farm MinRole.

2. You will need to scale the farm out to a total of nine servers in four tiers with the following server roles: two Front-end servers, two Application servers, three Distributed cache servers, and two Search servers.

3. If you start with a single site collection, it will be easy to administer permissions; you might have scalability issues, depending on just how big the body of content turns out to be.

You could consider starting with a single content database that has multiple site collections; this way, if you ever need to scale down the size of a content database, you could create a new content database, then move site collections to the new storage.

Scaling the site collections might cause you to reconsider your navigation strategy, moving from a structural to a managed navigation structure.