A SharePoint farm topology is used to describe the type or function of a particular SharePoint farm. When creating a SharePoint farm, roles are used to determine the functions of servers operating in a farm. There are eight server roles (seven predefined roles and one custom role), which are split across three categories:

• Dedicated roles
• Shared roles
• Special roles

These roles are used when deploying a chosen farm topology, as shown:

We'll look at those role categories and topologies next.

Dedicated roles

Dedicated roles are typically used in large-scale farms, but can also be used with smaller deployments or be added to servers that are configured for shared roles. The dedicated role layouts have been optimized for performance and scalability. The dedicated roles and descriptions are listed in the following table:

There may be situations where a farm design doesn't require dedicated roles, such as smaller departmental farms. In that case, you can use some of the pre-defined configurations, where functionalities are combined. We'll look at these shared roles next.

Shared roles

Shared role deployments are organized to allow a smaller number of servers in a farm by combining roles together. Shared role deployments can require more resources per server due to the increased number of components running. The shared roles and descriptions are listed in the following table:

Shared roles are common deployments for smaller farms (such as departmental farms or development farms). Next, we'll examine some special situations that require manual configuration.

Special roles

Finally, there is a special roles designation. Environments configured this way are typically used for development, testing, or for custom deployments where MinRole is not used to manage the services. The special roles and descriptions are listed in the following table:

If you decide to later change a server's purpose on a farm, you can change its role using SharePoint Central Administration. The only stipulation is that you can only convert a server into a Single-Server Farm role if it's the only server in a farm.

In the next section, we'll review the services that will be configured with the various MinRole deployment options. The services installed with each role are important so that you can choose the appropriate server roles for your topology to ensure you have the right components, as well as optimal numbers of servers to support the high-availability and performance requirements.

Role services

The MinRole server configuration process installs and configures the appropriate services for each role. The following table lists the installed roles based on the MinRole option chosen. Services listed in italics are hidden as they are not internal to SharePoint and are not intended to be directly controlled:

While the indicated services are normally hidden, they can be viewed through SharePoint Management Shell with the (Get-SPServer <server_name>).ServiceInstances command.

Knowing which services are grouped together will help guide your selection of farm topologies, which we'll look at next.

Farm topologies

A farm topology is used to describe a type of SharePoint farm. There are three core SharePoint farm topologies:

• Content farm: A content farm hosts sites and service applications. It's the most common and broad type of farm. Content farms optionally consume services applications from other farms.
• Services farm: A services farm hosts service applications that are consumed by other farms.
• Search farm: This specialized service farm hosts Search service applications that are used by other farms.

Each farm type requires a different mix of server roles in order to function correctly. The following table describes which roles are required for which type of farm:

After selecting which type of farm you'll design, you can choose which of the server roles from the preceding table are appropriate for the farm. Then, once you have identified the type of farm you want to design and deploy, you'll need to address the high availability and disaster recovery concerns.

When designing any system for high availability, a number of questions/concerns are typically addressed, such as the following:

• What types of failures should a system be able to sustain?
• How many failures should a system be able to sustain?
• What steps (manual or automatic) need to be executed to ensure availability?
• What systems or processes can we put in place to avoid interruptions in the first place?

These types of questions speak to the concept of dependability. A dependable system is one that is available to service a request and is able to continue serving requests despite failures of the component architecture (such as a server or network device) or supporting services (such as electricity). Dependability has six core attributes:

• Availability: Measures the system's readiness to accept and respond to new requests for service
• Reliability: Measures how a system can continue to operate after an unexpected event
• Safety: Measures a system's level of risk to users and the environment
• Confidentiality: The ability to control or prevent unauthorized disclosure of information
• Integrity: Measures the presence or absence of an improper system alteration (such as data corruption)
• Maintainability: A qualitative measurement for how easily a system is kept current, repaired, or updated

When designing a system, these ideas or attributes of dependability can be used when building a Fault-Error-Failure chain to help identify potential errors and solve them before they are expressed during operation.

From a practical standpoint, these questions of dependability can be broken up into four main categories:

• Fault forecasting
• Fault avoidance
• Fault removal
• Fault tolerance

Let's examine each of these with regard to designing a highly available SharePoint Server environment.

Fault forecasting

Fault forecasting is the prediction of likely or potential failures. With respect to SharePoint Server architectures, some of the following components come to mind:

• Server hardware, including components such as memory, chassis, power supplies, or mainboards
• Storage hardware, including components such as disk drives or other storage media, storage array software or firmware, or disk controllers
• Networking, including device (switch, router, firewall, proxy, and load-balancers) and cabling components, and inbound and outbound connectivity to the internet or other sites
• Power, including any power cables, switch boxes, outlets, power strips, uninterruptible power supplies, building or site power, and redundant power generation
• Software, such as application binaries or updates, Secure Sockets Layer (SSL) certificates, operating system binaries or updates, database servers, application services, and components

Each of those component categories represents one or more potential failures for an environment. In the forecasting stage, it's important to determine as many things as possible that can go wrong, as well as the likelihood and service impact of each.

Faults will happen in any environment, so devising strategies to identify potential faults and their impacts will help you design highly available systems.

Fault avoidance

Once potential faults in architecture have been identified, you can design around them. The premise of fault avoidance (or fault prevention) is to introduce elements that prevent faults. In the context of SharePoint Server architecture, this can mean several things, such as the following:

• Rigorous change control processes to understand modifications being made to the environment
• Development, test, or other sandbox-style environments where modifications are made and evaluated prior to production deployment

• Automated or scripted procedures to reduce the opportunity of human-caused failures
• Planning for redundancy and multiple failure modes

Fault avoidance is critical from both the design and operational perspectives to help ensure a high level of service and availability for a given service or application.

Fault removal

The goal of fault removal is to reduce the number and severity of service faults. Fault removal activities can be broadly divided into two categories:

• During the planning, design, or development of a system
• During the operation of a system

From a SharePoint Server perspective, removing faults during the development or planning of a system is the iterative process of identifying potential faults, such as disk drive or database failure (fault forecasting), designing a system to mitigate or prevent them (fault avoidance), and then performing testing that would trigger a particular failure mode.

For example, if you are planning for disk drive failure in a storage array, you would do the following:

1. Implement a storage subsystem with redundant features, such as disk mirroring.
2. Deploy an application or service utilizing the storage subsystem.
3. Introduce a failure, such as removing a disk drive, that would normally trigger a system failure.
4. Verify that the application or service continues to operate.

If the service or application fails to continue operating, you need to review the error logs and conditions, revise the deployment methodology or design, and then repeat the testing. Through this process, you can provide assurance to the business that the system will perform as designed.

Addressing the concept of fault removal during operation, using the previous example of disk drive failure, might look something like this:

1. The disk in the storage subsystem fails.
2. The disk subsystems continue operating in a degraded state.
3. The technician replaces the failed disk.
4. The system returns to a normal operational state.

In the preceding example, Step 1 is the failure mode. Step 2 indicates that the system's design has successfully resulted in continuing operations. In Step 3, the technician is performing fault removal by removing a failed device and replacing it with an operational one. In Step 4, the system has recovered and has returned to a normal operating state, free of faults.

In the previous failure scenario, the disk subsystem may have been designed to sustain the failure of a single disk drive. After the disk has failed in Step 1, the system is then at risk until the disk has been replaced in Step 3. The ability for a system to continue operation is compromised with each further fault, so it's important to minimize the amount of time between the steps.

Fault tolerance

Finally, the design goal of fault tolerance is to address how systems react when faults happen. As we've already stated, faults will happen. Fault-tolerant design plays a crucial role in allowing services to continue while faults are removed.

As a practitioner, you'll often be faced with choices and trade-offs to make on fault-tolerant designs, such as spending resources on redundant database hardware or additional servers in the SharePoint Server farm.

When designing highly available, fault-tolerant design for SharePoint, you'll likely need to incorporate the following components:

In the fault forecasting step, you identified potential failures that could affect the SharePoint Server system and designed methods in the fault avoidance step to help mitigate or reduce the impact of the faults on the environment.

In addition to fault-tolerant designs, you also need to make preparations for how to recover from catastrophic failures (such as a natural disaster) that spans all components in either a single fault domain or multiple fault domains.

In the next section, we'll look at using highly available designs to mitigate the impact of failures of various service databases.

Supported SharePoint high-availability designs

A SharePoint farm has many moving pieces. A successful highly available design requires understanding how the various components can be made resilient. The following table lists the database design considerations:

One of the common threads you'll see in the databases' availability design is the support for SQL Server AlwaysOn availability groups. Microsoft recommends AlwaysOn availability groups for all databases in a SharePoint Server environment from the perspective of same-farm high availability.

Service Applications support high availability behind load-balancers. After using the SharePoint product configuration wizard to configure a role for your server, add a configuration object (such as a virtual IP) to your load balancer that includes all of the servers hosting an application or service.

While a fault-tolerant and resilient design is important from a design and day-to-day operational perspective, you also need a plan for business continuity concerns in the event of a significant problem. That is where disaster-recovery planning is helpful.

Disaster recovery is the set of measures you undertake when your deployment has undergone a significant failure that exceeds the capabilities of your fault tolerance. Some example scenarios that might require disaster recovery efforts include the following:

• Storage failures: For example, if your storage environment has two redundant disk controllers and both of them fail before you can return the system to full capacity, or more than one disk fails simultaneously in a RAID-5 disk volume.
• Virtual machine host failures: If your environment comprises virtual machines and the underlying virtual machine hypervisors fail in a way that prohibits the virtual machines supporting your environment from powering up.

• Software updates: This could apply to operating system updates, application platform updates, driver updates, or other application updates that render the system unusable.
• Database failure: Since the majority of SharePoint Server's services rely on storing and retrieving information from databases, a catastrophic database failure could prohibit components in the farm from working correctly.
• Primary data center site compromise: Any event that impacts your primary data center, such as extended power outage, a flood or another natural disaster, network connectivity service interruption, or military action.

Your organization may require you to be prepared to resume activities in the event of any of these scenarios (or others that may apply to your environment). The ability to recover or restore operations is gauged by three measurements:

• Recovery Point Objective (RPO): The RPO can be expressed in several ways, such as "the last available backup from which to initiate a restore" or "the acceptable amount of data loss."
• Recovery Level Objective (RLO): A sub-function of the RPO, the RLO defines the granularities that you need to be able to recover (such as a data center, rack, host, farm, server, application, database, site, document library, folder, or file).
• Recovery Time Objective (RTO): The amount of time it takes to get a system operational with the data parameters of the RPO. This can also be referred to as how long the outage can last or "how long we're down."

A business recovery objective or requirement might be expressed as follows:

Must be able to recover a SharePoint farm at the document library level (RLO) in less than 2 hours (RTO) with no more than 2 hours of potential data loss (RPO).

As you put together a disaster recovery plan for SharePoint Server, it's important to start with the organization's goals (such as the number of hours of downtime or how much potential data loss is acceptable), and then recommend strategies, processes, and products based on that business requirement.

Outage costs

Outages fall into three categories, generally as follows:

• Planned loss of application or service (such as a service upgrade or scheduled maintenance)
• Unplanned loss of application or service
• Loss of data

Loss of an application or service may prohibit your organization from generating revenue or performing required activities for the business to operate, which may have a financial impact, depending on the application or service that is inoperable. An application or service can also incur a partial loss (such as running in a degraded fashion), which may render the system usable for some activities and not for others.

Planned outages are typically communicated to business users or customers and are scheduled to happen during low periods of activity. Unplanned outages, conversely, happen without notice due to some type of system failure.

Loss of data, depending on the type of data affected, could have a significant financial impact on an organization.

Depending on the type of application or data hosted by a SharePoint Server environment and the type of outage incurred, you may need to evaluate one or more disaster recovery options.

Disaster recovery options, costs, and considerations

Disaster recovery options (and their costs) can be quite varied, from a simple backup and restore to full standby data center solutions. Here are some example of disaster recovery options:

As with designing a fault-tolerance strategy, you'll also want to design a disaster recovery strategy that takes failure domains into account. These failure domains might include the following:

• Application, workload, database, or service
• Infrastructure or platform
• Farm
• Data center

Finally, no disaster recovery plan is complete without documentation that allows the technicians or support staff to return services to their full operational status. These operational recovery plans (sometimes referred to as runbooks or playbooks) should include things such as the following:

• Step-by-step printed instructions used to recover services from each failure or disaster mode, such as operating system installation and configuration, configuration, IP address schemes, or database names
• Tested scripts for building, deploying, and testing the configuration
• Operational procedures for restoring data
• Correct versions of software installation media and any applicable licensing information (such as key files, licenses, or other activation/registration information necessary to bring the service online)
• Emergency contact information for building access, infrastructure personnel, and application or business owners

Evaluating the business objectives (recovery time objective and recovery point objective) in conjunction with the budget will help you arrive at an appropriate disaster recovery strategy for your organization.

Next, we'll look at backup and restore as part of the SharePoint Server planning process.

Backups are an important part of designing and maintaining a SharePoint Server environment. The ability to backup and recover data is integral to many business processes, such as the following instances:

• Recovering or restoring accidentally or maliciously deleted content
• Platform or service upgrades
• Migrating between infrastructure solutions
• Recovering from failed upgrades
• Recovering from unexpected system failures or disasters

Natively, SharePoint Server supports the following backup designs:

• Farm
• Granular
• Configuration only

Let's examine these backup designs in more detail.

Farm

In a farm backup scenario, you'll be targeting backing up major components of the farm. The farm backup architecture is initiated from Central Administration and launches a SQL Server backup of content and service application databases. It also saves configuration content to files and backs up the Search index data.

A SharePoint farm backup supports both Full (all data) and Differential (data that's changed since the last full backup).

Within a farm backup, you can select the following nodes:

• Farm: The farm is the highest-level object. You can choose from the following selections:
  • Content and configuration data (default), which backs up the entire server farm (including settings from the configuration database)
  • Configuration-only, which only backs up the settings stored in the configuration database
• Web application: The Web application node represents the pieces necessary for an entire web application, including the following:
  • App pool name and account information
  • Authentication settings configuration
  • General web application settings, such as managed paths
  • Internet Information Services (IIS) site binding configuration, such as the protocol, port, and host header information
  • Changes to the Web.config file that were made through object model-based scripting or applications, as well as changes made through Central Administration (changes made manually are not backed up)
  • Sandboxed solutions (sandboxed solutions are stored in a web application's content databases)
• Services and service applications (not shared): Service and service application backups contain the settings for that service or service application, as well as any databases associated with it. If backing up a service application, the related proxy is not included. To fully protect the service application and its related application proxy, perform either a full farm backup or two consecutive backups with the service application in the first and the application proxy in the second.
• Proxies for service applications that are not shared: This is the application proxy only.
• Shared Services: Shared services require both a service application and an application proxy to run. Choosing the Shared Services node will back up all of the service applications and the corresponding service application proxies.

In addition, there are things that even a full backup doesn't cover (mostly related to the operating system and IIS configurations):

• Application pool account passwords
• HTTP compression settings
• Time-out settings
• Custom Internet Server Application Programming Interface (ISAPI) filters (configured through IIS)
• Computer domain membership, group membership, or organizational unit placement
• Internet Protocol security (IPsec) settings
• Network Load Balancing (NLB) settings
• SSL certificates or certificate trust stores
• Dedicated IP address configurations and settings
• Windows Firewall settings

For these settings, you will likely want to perform operating system backups or exports. Furthermore, there are a few additional caveats for farm-based backups that you should be aware of when planning a backup and restore strategy:

• The native SharePoint Server backup tools do not have a native scheduling interface. To perform scheduled backups, you will need to create a backup script of your own and schedule it using Windows Task Scheduler.
• SharePoint Server backup does not protect changes to Web.config made outside Central Administration or object model-based scripting solutions.
• SharePoint Server backup does not protect individual site customizations that are not part of a trusted or sandboxed solution.
• SharePoint Server backup does not protect trust certificates that have deployed for cross-farm solutions or service applications.
• Databases configured to use SQL FILESTREAM Remote Blob Storage (RBS) can only be backed up and restored to SQL database servers with the RBS provider installed.
• If your farm or applications use forms-based authentication, those settings must be manually configured after you perform a restore by registering the membership and role providers and redeploying the providers.

Any flat files that you backup through PowerShell or another export process can then be backed up using software such as System Center Data Protection Manager.

Granular

When backing up certain components (such as sites, workflows, customizations, web applications, or other individual components), you perform a granular backup. As you saw in the previous section, there are a number of tools you can use to perform various types of backups.

A granular backup, when using native tools, relies on Transact-SQL statements to export content. With the granular backup system, you can export or backup site collections and lists.

You can perform granular backups using native tools, including PowerShell, Central Administration, and SQL Management Studio. If you are using a version of SQL that supports database snapshots (such as Enterprise Edition), backups can trigger a database snapshot and allow users to continue accessing the site as normal. When backup utilizes database snapshots, you gain the added advantage of a totally consistent backup at a particular point in time. The downside is that it is a more I/O-intensive operation to perform a database snapshot, so users may experience a brief slowdown when the database snapshot is initiated.

Whichever method you choose for performing a backup (whether you are using full farm backups or more granular backups), you'll have a route to restore your environment or its components should unexpected circumstances arise.

Configuration only

With a configuration-only backup, you are only backing up the server or farm configuration without any data. This type of backup might be useful for replicating farm configurations in conjunction with disaster recovery preparation or building test and development environments. Depending on the mechanism used, you can back up either the entire farm configuration or parts of the farm or server configuration using either the Central Administration interface or by using PowerShell.

Central Administration

By performing a configuration-only backup with SharePoint Server Central Administration, you can back up the configuration of the farm. The Central Administration configuration backup method can only be used to back up the full configuration of the local farm. It cannot be used to back up a remote farm or a disconnected configuration database.

To perform a farm backup using Central Administration, follow these steps:

1. Verify that the user account performing the backup is a farm administrator.
2. Navigate to the Central Administration page. Under Backup and Restore, click Perform a backup.
3. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the farm from the component list browser, then click Next.
4. On the Start Backup — Step 2 of 2: Select Backup Options page, select Full in the Backup Type section.
5. In the Backup Only Configuration Settings section, select Backup only configuration settings.
6. In the Backup File Location section, enter the Universal Naming Convention (UNC) path of the destination backup folder, then select Start Backup.

The UNC path will contain a backup that can further be moved to offline media and preserved.

PowerShell

When using the Backup-SPConfigurationDatabase PowerShell cmdlet to perform a configuration-only backup, you can overcome the limitations of performing a backup with Central Administration. PowerShell-based backups allow you to backup configurations from either local or remote farms, as well as disconnected configuration databases.

Performing the backup from PowerShell, depending on the target configuration database, may require additional permissions. Generally speaking, the account that is used to perform the backup must have the following permissions or memberships:

• A db_owner fixed database role on all of the databases being backed up or updated
• A securityadmin fixed server role on the SQL server instance where the databases are hosted
• Membership to the local Administrators group on the server where Backup-SPConfigurationDatabase is being executed
• Membership to the WSS_ADMIN_WPG local group on the server(s) where SharePoint products are installed
• A SharePoint_Shell_Access role for the databases that are being acted upon
• Optionally, the db_backupoperator fixed database role for the databases being backed up or updated

You can use the Add-SPShellAdmin cmdlet to grant the account used for PowerShell administration access to the SharePoint_Shell_Access role to specific databases. It is recommended that you specify which databases to use with the -Database parameter as that will add the named account to the farm configuration database, the Central Administration content database, and the database specified in the parameter, as well as to the WSS_ADMIN_WPG group on all SharePoint web servers.

You can use a function or PowerShell script, such as the one in the following code block, to accomplish the task of adding an additional administrator to the SharePoint farm. Copy and paste the following script into SharePoint Management Shell, then run New-FarmAdmin -Identity <username> -IncludeAllContentDatabases:

Function New-FarmAdmin ([string]$Identity,[switch]$IncludeAllContentDatabases)
{
    $CentralAdminWebApp = Get-SPWebApplication –IncludeCentralAdministration | `
    ? {$_.DisplayName –like "SharePoint Central Administration*"}
    New-SPUser –UserAlias $Identity –Web $CentralAdminWebApp.URL –Group "Farm Administrators"
    $CentralAdminContentDB = Get-SPContentDatabase –WebApplication $CentralAdminWebApp
    Add-SPShellAdmin -Database $CentralAdminContentDB -Username $Identity
    If ($IncludeAllContentDatabases)
    { 
       $ContentDatabases = Get-SPContentDatabase
       Foreach ($Database in $ContentDatabases) 
       {
          Add-SPShellAdmin -Database $Database -Username $Identity
       }
    }
}

You must also have write access to the network share path that will be used as the destination for the backup. The Backup-SPConfigurationDatabase cmdlet is used to initiate a backup.

To perform a configuration backup using PowerShell, perform the following steps:

1. Launch SharePoint Management Shell.
2. Run Backup-SPConfigurationDatabase -Directory <BackupFolder> -DatabaseServer <DatabaseServerName> -DatabaseName <DatabaseName>.

Be sure to specify the -Directory parameter value destination as \\server\share.

Both planning for disaster recovery scenarios as well as day-to-day backup and restore scenarios are crucial to ensuring your data is protected from destruction or environment failure. In the next section, we'll discuss how Information Rights Management (IRM) can be used to protect your information in another way—from unauthorized use, tampering, or leakage.

IRM is the set of policies and protections used to govern the actions that users can take on documents stored in SharePoint. IRM relies on some form of Rights Management Services. SharePoint Server, depending on the version, supports the use of Active Directory Rights Management Services (all on-premises versions) or the corresponding cloud version, Azure Rights Management (through the use of the Rights Management Services connector for SharePoint Server 2010, SharePoint Server 2013, and SharePoint Server 2016) to protect assets. Additionally, Azure Information Protection is a rights management-based protection that can be applied at the individual file level (whether a file is in a SharePoint library or not), making it an ideal method for protecting data across an enterprise.

Determining which solution is best for your organization depends on both your current infrastructure and knowing what the technology roadmap for your organization entails. Most organizations will leverage more cloud services over the course of time, so it is best to understand what direction your particular organization will take.

While it is important to understand that both the Active Directory Rights Management and Azure Rights Management platforms are supported by SharePoint Server 2016, this book will focus on utilizing Azure Rights Management and Azure Information Protection. Both Azure Rights Management and Azure Information Protection are available cross-premises.

All of the rights management protection schemes allow document owners (or document library owners) to protect supported documents—typically, this includes Microsoft Office formats as well as the XML Paper Specification (XPS). The information protection technology that is deployed determines what file formats and types can be protected. For example, native SharePoint Server 2016 or 2019 IRM only supports Office file formats and XPS, while Azure Rights Management supports many additional common document formats. For more information on the exact file formats supported, see https://docs.microsoft.com/en-us/azure/information-protection/rms-client/client-admin-guide-file-types.

Depending on the product that is implemented (Active Directory Rights Management, Azure Rights Management, or Azure Information Protection) and the location (document library, document, or email), some or all of the features, permissions, or usage rights may be able to be applied:

• Edit: Allows a user to modify the content stored in a document's associated application. It does not natively grant the ability to save the document.
• Save: Allows the user to save the document to the current location. Depending on the application, users may also be able to save the document to a new location.
• Comment: Enables the option to add comments or annotations.
• Save As or Export: Allows the user to save the content to a different filename or export content. This also supports exporting content to different applications (such as Send to OneNote).
• Forward: Enables the user to forward an email to additional users and modify the To or Cc lines. Note that this only applies to an actual email message and has no bearing on the rights present in any attached document.
• Full Control: Enables all rights to a document, including the ability to add or remove protections and restrictions.
• Print: Enables the option to print content.
• Reply: Enables the ability for users to reply to the sender of a rights-protected email.
• Reply All: Enables the ability for users to reply to all To or Cc recipients in a rights-protected email.
• View, Open or Read: Allows the user to open a document or email and see the content. This does not allow users to change the contents of a document (for example, sorting or filtering a column in Excel). Clicking on the content in a protected document frequently requires some form of the Edit permission.
• Copy: Allows the ability to copy the content or perform screen captures.
• View Rights: Enables a user to view the rights assigned to a document.
• Change Rights: Enables a user to change the rights policy applied to a document, including the ability to remove all protection from a document.
• Allow Macros: Enables a user to run a macro or enable other programmatic access in a protected document.

With that being said, when planning for IRM, you'll need to understand the SharePoint environment, what software clients or applications will be used, where the rights need to be applied, and which supported technologies are available.

Part of any SharePoint Server deployment instance is understanding the intended target audience. SharePoint Server supports some level of localization. Localization is the concept of SharePoint displaying content in a different language than it may have been created in. Multilingual features enable users to see sites in their preferred languages.

SharePoint Server supports two core types of localization:

• Multilingual user interface
• Variations

In the next two sections, we'll explore the features and use cases for both of them.

Multiple Language User Interface

With the Multiple Language User Interface (also referred to as the Multilingual User Interface or MUI), you can configure SharePoint Server to display interface elements in a user's preferred language. MUI configurations affect the elements that are used to manipulate and interact with SharePoint, such as navigation items. When using the MUI, you can display the following user interface elements in different languages:

• Default columns
• Navigation bar links
• SharePoint default menus and actions
• Custom columns for a list or site
• The site title and description
• The Managed Metadata services

When planning to use MUI features, you'll need to understand the languages that your users commonly use. MUI features require the installation of language packs for the languages that you want to use.

MUI features are configured at the site level. To change them, follow these steps:

1. As a site collection owner or administrator, navigate to the site where you wish to enable multiple language support.
2. Click Settings | Site Settings. Depending on whether the site is on the modern or classic version or has been customized, you may need to select Site Information | View all site settings on the Site settings fly-out menu.
3. On the settings page, under the Site Administration section, click Language Settings.
4. Select the checkboxes for the languages you want to make available.
5. Click Yes under Overwrite Translations if you want to overwrite translations in the site interface when changes are made to the default site interface. If other administrators make changes in alternative language versions of the page (such as updating the translated text for a navigation item), selecting Yes on this setting will cause the changes made in the default interface to overwrite the customized changes in an alternative language interface.
6. Click OK.

It's important to note that while navigational items or list columns will be translated, the content will not.

Variations

While the MUI is used to translate navigational and interface elements, variations can be used to actually translate content. This can be useful if you have content that needs to be replicated in several languages. Variations require sites to be built with the Publishing Site templates, which includes workflows and timer jobs to update pages.

Variations rely on the configuration of several elements:

• Variation root site: The root site provides the URL for the variation sites. It hosts the landing page that will redirect users to the correct site.
• Variation labels: An identifier for a variation. Each unique variation needs to have its own variation label defined.
• Variation sites: Sites that are created and managed based on the variation labels.
• Source variation sites: Denotes sites where content is authored, curated, and published. A source variation site's content is synchronized with the target variation sites. A site collection can only host one source variation site.
• Target variation sites: Denotes sites that receive synchronized copies of content from source variation sites. Target variation sites can also host new, unique content (though that content is not synchronized to other sites).
• Variations hierarchy: A complete set of sites with all variation labels.
• Variation lists: Lists for which you identify target variation labels to receive list items.
• Variation pages: Publishing pages stored in the Pages library of the source and target variation sites.

When planning a variations-based deployment, there are several important things to consider:

• Content approval: As previously noted, the use of variations requires SharePoint Server Publishing Site templates. In order for new content to be synchronized and made available on target variation sites, it must be approved by the source variation site administrator(s) or member(s) with approval permissions. As content is only visible once it has been approved, part of the planning process needs to focus on who is responsible for both creating and approving content to be pushed to sites that will have variations. Variations and content approval require major and minor versioning enabled in the source and target variation sites.
• Content deployment: Content deployment jobs are used to copy content from one site collection to another. If you plan on using content deployment jobs to sync content into a source variations site, you need to ensure that the content deployment job schedule doesn't overlap with the Variations Create Hierarchies Job Definition job. If they execute at the same time, you risk inconsistent site data being synchronized from the source to target variation sites.
• Cross-site publishing: Cross-site publishing is a feature that allows content from one site to be shown in another site's search results. The source (or authoring) site collections are used to author and contain content and then a publishing site is used to control the design and show the content. The authoring sites contain catalogs (content that is tagged with various metadata). The publishing site collection uses Search web parts to display cataloged content based on the filters the site author selects. There are three core scenarios for cross-site publishing in variations or multilingual sites, each of which has their own architectural and planning guidance (see https://docs.microsoft.com/en-us/sharepoint/administration/plan-variations-for-multilingual-cross-site-publishing-site for more detailed deployment and configuration information):
  • Maintaining multilingual content outside of SharePoint
  • Only publishing multilingual content, or publishing a mix of catalog- and non-catalog-based content, without variations on the non-catalog content
  • Publishing a mix of catalog and non-catalog content with variations on all content
• Site navigation: Like cross-site publishing, site navigation in variations-based sites has additional planning requirements. Site navigation is automatically generated and displayed in the Global Navigation and Current Navigation menus of a web page. Depending on your layout, this may or may not be a desirable feature.
• Web parts: Web parts are used to display content on SharePoint pages. Web parts are synced by default as part of the variations configuration. Depending on the type of content displayed in a web part, it may be desirable to disable web part updates to target variations sites.

Regardless of the translation mechanisms that are used, it's important to determine what languages your users need and what mechanisms you will use (manually creating and updating content, MUI items, and custom or third-party translation services).

Localization settings will help you tailor your content to the language needs of your individual users. In the next section, we'll talk about how and where to store the content and applications themselves—in SharePoint Server content farms.

For many organizations, a single content farm is the most practical and simple choice to deploy. Utilizing some of the design concepts discussed earlier in this chapter (MinRole farm topologies and high availability), you can choose from some of the recommended design patterns, depending on your organization's budget and performance needs:

Utilizing one of the built-in MinRole server roles (selected in the SharePoint Products Configuration wizard), you can choose where you want to invest resources, ranging from four highly available servers, each running two shared roles, and up to eight (or more) servers configured with dedicated roles. It is important to understand the MinRole deployment topologies and the components required for high availability from a design perspective to ensure you're in a supported design pattern.

In the next section, we'll look at extending the on-premises topology into Office 365.

While SharePoint Server has a very large feature set, you may need to connect an on-premises SharePoint environment to Office 365—whether that's extending your environment out to Office 365 or accessing on-premises content from Office 365. The following features can be integrated between SharePoint Server and Office 365 components:

• OneDrive for Business: Hybrid OneDrive for Business configures users to be redirected to OneDrive for Business in Office 365 when they access OneDrive in SharePoint Server.
• Sites: Hybrid sites allow you to integrate navigation between SharePoint Server and Office 365.
• Search: Hybrid search scenarios allow you to configure a search environment that allows users to locate content in Office 365 or local SharePoint farms from either search environment.
• Business Connectivity Services: Allows access to on-premises data using Business Connectivity Services.
• Power Apps, Power BI, and Power Automate (formerly Microsoft Flow): Using a data gateway, you can connect the newest Office 365 Power Platform applications (Power Apps, Power Automate, and Power BI) to on-premises environments.

All of these features require running the SharePoint Hybrid Picker application to configure hybrid features, with the exception of configuring the data gateway for Power Platform integrations.

Choosing which types of integrations you need to deploy will depend largely on the business and use cases for your farm. For example, you may need to deploy a solution that requires SharePoint Server features and the ability to synthesize datasets that are in other on-premises systems, but also want users to be able to take advantage of Office 365's OneDrive for Business. Alternatively, you may have data in legacy on-premises farms that you're not planning to migrate to Office 365, but you want users to be able to find and access it from a single search view in Office 365.

An understanding of the use cases and any limitations for existing infrastructure largely determines what Office 365 workload integrations you will need to use.

The OneDrive sync client is used to synchronize data, typically between a user's personal computer and their server-based OneDrive (also known as My Sites) document library.

The newest version of the OneDrive sync client works with both SharePoint Server and SharePoint Online, so depending on which one your organization uses (or plans to use), you may want to specify some additional configuration settings.

Planning Group Policy configuration settings

When planning your OneDrive sync client, there are a number of configuration items to address. Many of these configurations can be managed with Group Policy objects for the OneDrive client:

• Specify the SharePoint Server URL and organization name: When OneDrive for Business is configured against Office 365, a staging folder for the OneDrive client is created using the Office 365 tenant's name as a prefix. For example, if the tenant ID name is contoso.onmicrosoft.com and the organization is Contoso, Ltd., the OneDrive for Business folder would (by default) be named C:\Users\<username>\OneDrive - Contoso, Ltd.. On-premises works a little bit differently. SharePoint Server uses the prefix of the SharePoint URL to create the folder name. For example, if your SharePoint environment's name is spfarm.contoso.com, then the organization name that the OneDrive client will use is spfarm (and the resulting folder name would be C:\Users\<username>\OneDrive - Spfarm). Depending on your plans for Office 365 or OneDrive for Business in the future, you may wish to make the organization name reflect the value in an Office 365 tenant, if you have one. This setting is located under Computer Configuration | Policies | Administrative Templates | OneDrive:

• Specify the OneDrive location in a hybrid environment: If your organization has deployed both Office 365 OneDrive for Business and SharePoint Server, you may want or need to decide which personal storage service users will access. You can use this policy setting to determine whether users will authenticate to Office 365 (SharePoint Online) first or to a local SharePoint system. This policy object is located under Computer Configuration | Policies | Administrative Templates | OneDrive:

• Use OneDrive Files On-Demand: Files On-Demand is a new feature that allows you to save local disk space by storing a shortcut in the OneDrive sync folder to the content stored in SharePoint. Depending on your deployment constraints (such as non-persistent virtual desktops, devices with small local disk storage, or organizational policies that limit data storage on local devices), it may be preferable to use this feature to prevent the automatic synchronization of data when the OneDrive client starts. It requires Windows 10 Fall Creators Update (version 1709 or later), OneDrive sync app build 17.3.7064.1005 or later, and SharePoint Online or SharePoint Server 2019. The Files On-Demand feature is located under Computer Configuration | Policies | Administrative Templates | OneDrive.

In addition to these popular settings, there are several other OneDrive settings that may be useful when planning an OneDrive deployment. For a complete list of One Drive Group Policy settings, see https://docs.microsoft.com/en-us/onedrive/use-group-policy.

Deploying OneDrive administrative templates

If you have not yet deployed OneDrive template files previously in your organization, you can follow these steps to make the Group Policy settings available:

1. Download and install the most current OneDrive sync app for Windows. To obtain the latest version, go to https://go.microsoft.com/fwlink/?linkid=823060.

2. Once it has been installed, navigate to %localappdata%\Microsoft\OneDrive\BuildNumber\adm, where the build number is the latest version of the OneDrive app (which you can find on the Settings | About page of the OneDrive app):

3. Copy the .adml and .admx files.

4. Navigate to the SYSVOL policies container for your domain (typically \\domain\sysvol\domain\Policies) and expend the PolicyDefinitions folder. If the PolicyDefinitions folder does not exist, create it. In the PolicyDefinitions folder, create another folder for your language (for example, en-us).

5. Paste the OneDrive.admx file in your domain's PolicyDefinitions folder and paste the OneDrive.adml file in the specific language folder (for example, PolicyDefinitions\en-us).

Once the templates have been deployed, you can create a new Group Policy configuration for OneDrive and update the necessary policy objects.

In the next section, we'll discuss some of the steps you can take to get the best performance possible from your SharePoint environment.

Virtualization is an enterprise for the architecture of most workloads and services in modern data centers. Virtualization brings a lot of benefits to computing, such as the improved capability to both horizontal and vertical scaling, to be able to add layers of host redundancy to support highly available solutions.

However, virtualization also introduces potential pitfalls, such as overcommitting hardware resources.

SharePoint Server is fully supported on virtualized platforms, as well as on traditional bare-metal platforms. Virtualization adds a layer of abstraction to the entire process, potentially making it more difficult to understand all of the components affecting your environment's performance.

The areas that we'll look at include the following:

• Core requirements
• Server infrastructure
• Processors
• Server roles
• Storage
• Network
• Database

Let's review each of these areas in the coming sections.

Core requirements

SharePoint Server 2019 has the following minimum hardware requirements:

When planning for a highly performant, highly available server deployment, it is recommended that you choose a MinRole topology with dedicated server roles and redundant components. Current information on the SharePoint Server requirements can be found on the requirements page at https://docs.microsoft.com/en-us/sharepoint/install/hardware-and-software-requirements-2019.

Server infrastructure

As previously stated, most modern data centers utilize a high amount of virtualization. Virtualization, in and of itself, is a mechanism that allows a server (or host) to run more than one instance of a particular type of software (whether it's a full operating system running as a virtual machine, such as Windows Server 2019, or a container system, such as Docker, running applications).

In either of these cases, virtualization requires some overhead to allow the virtualization software to coordinate resources for the virtual machines or containers. This overhead subtracts from the overall amount of CPU cycles available to a service application and user requests.

With that being said, most SharePoint deployments will utilize virtual machines for some or all of the functions. Many organizations still choose to run database servers (due to their high transaction rates) in a more traditional fashion. If your organization chooses a virtualization strategy to support a SharePoint system, you will need to plan accordingly to ensure that the virtual infrastructure provided can meet the performance and user experience requirements of your organization.

Processors

Processors perform the computational tasks necessary to render content and applications. Per the minimum requirements, Microsoft recommends (four) 64-bit processor cores for a SharePoint Server instance. Task and context switching has a high degree of impact on overall performance. If your organization chooses to use virtualization, be careful to not oversubscribe or overcommit the number of processing resources presented to virtual machines.

Server roles

In the Selecting and configuring a Farm topology section of this chapter, we discussed the different roles available, particularly Dedicated versus Shared.

Shared roles, by their nature, take up more system resources than dedicated roles. Shared roles also introduce the potential for more task switching (time that the computer spends switching between threads to process transactions). For the highest-performing farm, it is recommended that each server performs only one role or function in a SharePoint farm. SharePoint services can be scaled both horizontally and vertically to accommodate multiple performance scenarios.

Storage

Storage (as a physical resource) is arguably one of the most important parts of a high-performance solution. Nearly all content and data stored or accessed inside a SharePoint environment is stored in some sort of database, which in turn rests on physical storage media. Storage is important to a SharePoint environment in two ways: the amount of data volume (capacity) and the speed at which data can be stored or retrieved.

When determining storage requirements for a high-performance system, there are a number of items to consider:

• The number of transactions (such as uploading, downloading, viewing, and so on), each of which generates I/O activity and is measured in I/O Operations Per Second (IOPS)
• The number of documents or other artifacts stored (and their associated metadata)
• The amount of data volume, including versioning

The general rule of thumb is to plan for I/O requirements first. A system's storage performance is generally governed by how many individual disks can be tasked at a particular time to act on data.

An individual disk's IOPS can be calculated using the following formula:

1000/(average disk latency + average disk seek time)

For example, a high-end 15,000 RPM mechanical drive with a seek time of 2.5 ms and a latency of 1.7 ms results in an IOPS value of 238. Typical mechanical hard drives deliver an IOPS ranging from 55 to 250, while SSD drive performance delivers 3,000–40,000 IOPS per disk.

Utilizing the principles you learned earlier for fault-tolerant design, you need to make sure that you design your storage in a way that can withstand the failure of one or more disk components. Disk subsystems typically achieve redundancy and performance using a mixture of technologies and configurations:

• RAID
• Multipathing
• Disk configurations
• Database capacity

Let's examine how each of these affects the storage infrastructure.

RAID

A RAID solution is a storage architecture that combines various aspects of performance, fault tolerance, and storage management. It is a form of storage virtualization, combining all or parts of physical disks to present a contiguous, logical allocation of storage to a host.

A group of disks operating in a RAID configuration is known as a RAID set. RAID subsystems work by saving data in either a striped (split into chunks and distributed) or mirrored (duplicated) fashion to the disks in the RAID set. Different combinations of striping and mirroring are referred to as RAID levels.

Additionally, RAID sets can include a feature called parity, which is a mathematical computation performed on data as a sort of error checking mechanism. In the event of disk failure, parity can be used to recover or rebuild the data on the inoperable disk. A RAID set is set to be in a degraded state when one or more disks in the set have failed but the volume as a whole is able to continue servicing requests.

To a large extent, a particular RAID set's performance depends not only on the RAID level but also on the read/write ratio. The read performance of a RAID set can be calculated using the formula. Each level has its own set of performance and redundancy characteristics, the most common of which are displayed in the following list:

• RAID 0: A RAID 0 configuration offers no fault-tolerance benefit. Data is striped between two or more disks evenly. In the event that any single disk in a RAID 0 set fails, all of the data is lost. RAID 0 provides a high level of overall read and write performance since it can engage multiple disks simultaneously to store and retrieve data. RAID 0 also provides the most possible storage, since there is no capacity overhead used to provide redundancy:

A RAID 0 set's performance can be expressed by simply multiplying the number of IOPS per disk and the number of disks—for example, a four-disk RAID 0 set with disks that can each perform 125 IOPS results in a max throughput of 1,000 IOPS.

• RAID 1: RAID 1 is the exact opposite of RAID 0. While RAID 0 has no fault tolerance whatsoever, RAID 1 can sustain the failures of up to half of the disks in a set. RAID 1 is commonly known as drive mirroring because incoming data is simultaneously written to two (or more) disks. RAID 1 only works with even numbers of disks. A two-disk RAID 1 set has a 50% capacity overhead as each disk has a full copy of all of the data. A two-disk RAID 1 set also has a 50% performance reduction on write activities since the data must be written twice. This configuration is commonly used for operating system drives:

• RAID 5: A RAID 5 set utilizes disk striping (dividing a piece of data into multiple blocks and spreading those blocks among multiple drives) as well as parity (an error-checking calculation that is stored as a block on a drive). Effectively speaking, one drive of a RAID set is dedicated to storing parity calculations. RAID 5 requires a minimum of three drives to implement (which means a 33% storage capacity overhead). The most common configuration utilizes four drives, resulting in a 25% storage capacity overhead. RAID 5 volumes have very fast read times as multiple disks are being engaged. However, they do have a bit of performance overhead when both computing parity for writing as well as computing parity on the fly when the set is in a degraded state. This configuration is commonly used for file shares or database volumes with low to medium activity:

• RAID 6: Building on the parity concept of RAID 5, RAID 6 introduces an additional parity bit to allow a drive array to sustain failures on two drives. This increased parity leads to both a reduction in storage capacity as well as increased performance overhead since parity is computed and written twice. RAID 6 volumes require a minimum of four disks to implement. This configuration is commonly used for file shares or database volumes with low to medium activity:

• RAID 10: RAID 10 is a combination of the capabilities of both RAID 1's mirroring and RAID 0's striping. It's commonly configured with four disks. RAID 10 has excellent read performance, as well as a 50% write performance penalty. RAID 10's total capacity is 50% of the disk capacity, but it can recover from up to two failed disks. This configuration provides both the highest performance and highest recoverability, but it also incurs the highest unusable amount of unusable storage—effectively, half the disks in the array. RAID 10, from a performance and resilience perspective, is typically the best choice for high-volume databases:

As you can see from the preceding diagrams and explanations, a RAID 10 disk subsystem is likely the best choice for high-performance SharePoint farms. Microsoft recommends the use of RAID 10 for SharePoint and SQL server configurations.

Multipathing

From a storage connectivity standpoint, multipathing allows a computer to connect to external storage through more than one route. Multipathing is typically configured when connecting to Storage Area Networks (SANs) via iSCSI or fiber storage networking. Configuring multipathing requires either multiple single-port storage adapters or a single multi-port storage adapter and a multipathing software package.

If your SharePoint farm or SQL database server environment uses physical servers (as opposed to virtualized servers), multipathing is an excellent way to provide both storage redundancy and storage performance.

Disk configurations

If you are using virtual machines in your SharePoint environment, you should evaluate the way you attach them to physical storage, including the following:

• Disk connection methods
• Fixed versus dynamic or thin-provisioned volumes

When you connect or attach disks to a virtual machine and begin configuring it, you generally have three options: exposing raw disk storage (in Hyper-V, this is referred to as a pass-through disk) to the virtual machine, connecting to raw disk using iSCSI or using Network Attached Storage (NAS)), or provisioning a VHD/VHDX file on a storage array and attaching that to the virtual machine configuration.

In earlier versions of Hyper-V, pass-through disks were generally considered the fastest method because there were fewer layers between the virtual machine and the disk access. Modern Hyper-V boasts a negligible difference, so it is probably best not to use them as they could present challenges to high availability or snapshots. You may want to test the performance between direct attach storage methods (such as iSCSI) to see whether they yield any performance gain.

If you decided to provision standard VHD/VHDX virtual hard drive files, it's important to provision them as fixed disks (where the entire volume of the virtual disk is pre-allocated) as opposed to using dynamically expanding disks (sometimes referred to as thin provisioning). Using thin provisioning or dynamically expanding disks greatly reduces the performance of a disk's volume since the storage is no longer contiguous. Disks serving the I/O requests will likely have to travel more to read or write data, introducing latency into the equation.

Database capacity

Part of the storage planning calculation is knowing (or estimating) how much data is stored. When calculating capacity needs, the following formula can be used:

Content database size = ((D × V) × S) + (10 KB × (L + ( V × D)))

Here, we have the following:

• D is the number of documents to be stored, including any growth (most organizations tend to estimate growth over a period of 3 or 5 years). For computing departmental or project sites, you may want to use a number such as 10 or 20 documents per user; for My Sites, you may want to use a larger number (such as 500 or 1,000 per person).
• V is the number of versions that are stored (must be non-zero).
• S represents the average size of a document. Depending on the sites that will be stored in a particular content database, it may be useful to re-estimate this value for each content database (for example, My Sites will likely have a different usage profile than a departmental or project site).
• L is the estimated number of list items per site. If you have no pre-existing estimates, Microsoft recommends using a value of three times the amount of D.
• 10 KB represents the amount of storage volume consumed by metadata. If you plan on deploying a very metadata-driven environment, you may wish to adjust this number.

By applying the preceding formula to the following values, you can calculate the amount of storage capacity that a particular content database might be projected to need:

The calculation is as follows:

Content database size = (((500,000 x 5)) x 50) + ((10KB * (1,500,000 + (500,000 x 5))), or 165 GB of total storage.

Network

In order to produce a high-performance farm, you also need to ensure that the network connectivity between servers is optimal. Generally speaking, you should adhere to these guidelines:

• All servers should have a Local Area Network (LAN) bandwidth and latency to SQL servers used in the SharePoint farm. The latency should be 1 ms or less.
• Microsoft does not recommend connecting to a SQL environment over a Wide Area Network (WAN).
• If configuring a site-redundant solution with SQL AlwaysOn located in a remote data center, you should ensure that you have adequate WAN bandwidth to perform the necessary log shipping or mirroring activities.
• Web and application servers should be configured with multiple network adapters to support user traffic, SQL traffic, and backup traffic.
• If connecting to iSCSI storage, ensure that any iSCSI network adapters are configured to only be used for iSCSI communication and not normal network communication.

These recommendations will help you build a farm that is both resilient and high-performing.

Designing a performant, reliable, SharePoint environment takes a lot of planning. Some of the areas that we touched on in this chapter included resilient and fault-tolerant design principles, using MinRole to manage server role deployments, and disaster recovery planning and scenarios.

Accessibility is also an important factor to consider when architecting an environment. We reviewed how localization can help make SharePoint content accessible to users with different language needs. Security is a large part of any modern system design; we discussed how Azure Information Protection and Rights Management services can be used to manage access and control the actions that others can perform against documents.

SharePoint Server 2019 is a capable content management and application platform and can be integrated with numerous Office 365 workloads and provide user experiences that cross platforms. This ability gives users and organizations the best of each platform's capabilities.

Finally, you learned about some of the steps you can take to design a high-performing farm, including processor, memory, storage, and networking recommendations.

In the next chapter, you will learn how to effectively manage and maintain a SharePoint farm environment, involving tasks such as configuring service applications and managing storage.