+- On the Mac, if the guest account was created with a different email address format than the form they are using with the sync app, the external site's content cannot be synced. For example, <first.last@fabrikam.com> vs <alias@fabrikam.com>.

+You must type the name for the computer that is running a supported version of the 64-bit edition of SQL Server 2014 SP1. You can type the name of the computer that is running SQL Server as either server or server\instance.

+If you're creating a new configuration database, you can either type the name of the database for the configuration wizard to create, or you can type the name of a database that has been provisioned in advance. If you want to use an existing database you must run Psconfig.exe from the command line to connect to that database, and it must not contain any tables, stored procedures, or other objects.

+If you're connecting to an existing configuration database, you can click **Retrieve Database Names**. The configuration databases that exist on the computer that is running SQL Server will be returned, and you can choose the appropriate configuration database.

+Although you can enter either a local or a domain account in installations in which you're using a SQL Server installation, a local account will work only for single-server deployments. We recommend that you use a domain account so that you preserve the flexibility to later add more computers to the farm.

+To deploy SharePoint products in a server farm environment, you'll need a unique domain user account that you can specify as the SharePoint service account. This user account is used to access the configuration database. The database access account will be used for both initial database configuration, and ongoing connections from servers in this farm to the databases.

+This account also acts as the application pool identity for the SharePoint Central Administration application pool and it's the account under which the SharePoint Timer service runs. The SharePoint 2016 Products Configuration Wizard adds this account to the SQL Server Logins, the SQL Server Database Creator server role, and the SQL Server Security Administrators server role. We recommend that you follow the principle of least privilege and don't make this user account a member of any particular security group on your web servers or your database servers.

+The database access account must have the following permissions: security administrator, database creator, and database owner (DBO) of all SharePoint databases. If you run Psconfig.exe from the command line to install and specify the account using SQL authentication, then permissions for this account must be configured in SQL Server. The configuration wizard doesn't perform this configuration when you run the Psconfig.exe file from the command line with the SQL authentication option.

+After applying September 2018 .NET 4.6 or later updates, the crawl will fail and you'll see similar following entries:

+The configuration section for `SqlColumnEncryptionEnclaveProviders` isn't defined but it's required by .NET Sql Client.

+Create a config file for mssdmn.exe if it doesn't exist already (by default it doesn't). Ensure the config file has the following content:

+3. The usage events are sent to the **Analytics Processing Component**, where they're analyzed. The result is sent to the **Search index**.

+This is especially important in a cross-site publishing scenario (see [An introduction to cross-site publishing in SharePoint Server](an-introduction-to-cross-site-publishing.md)). With cross-site publishing, content is stored in an Authoring site collection and displayed in a Publishing site collection. Managed navigation is used together with category pages and catalog item pages to display content (see [Stage 8: Assign a category page and a catalog item page to a term in SharePoint Server](stage-8-assign-a-category-page-and-a-catalog-item-page-to-a-term.md)). This means that when a visitor views an item on the publishing site, the usage event happens on the catalog item page, for example `http://www.contoso/sites/Pages/ContosoItemPage.aspx`. Because the same catalog item page is used to display many items, the usage event can't be recorded using the URL of the catalog item page. For Usage analytics to work in a cross-site publishing scenario, the usage event must be recorded using the URL of the item in the authoring site collection, for example `http://www.contoso/sites/catalog/Lists/Products/DispForm.aspx?ID=12`.

+Depending on how you've set up your website, SharePoint Server can automatically record the usage event on the URL of the item in the authoring site. Here's the question that you must ask yourself: which Web Part are you using to display items on your catalog item page? If the answer is Catalog Item Reuse Web Parts, then you have nothing to worry about. The Catalog Item Reuse Web Part will automatically make sure that usage events are recorded correctly in the Event store. But, if you're using a Content Search Web Part to display items on your catalog item page, you must do some extra configuration steps. But don't worry, all these steps will be explained later in this series.

+The two recommended keyboards are the same product, and so are the two mouse devices. These aren't good recommendations. To get recommendations that will ignore the product color, we have to change the mapping of the *UsageAnalyticsID* managed property.

+An administrator of a SharePoint Server service application must be a member of the Farm Administrators group to assign or remove other administrators to that service application. Service application administrators are granted security-trimmed access to the SharePoint Central Administration Web site and can manage settings related to the service application but must be a member of the Farm Administrators group to add and remove other service application administrators.

+You can assign or remove service application administrators by using the SharePoint Central Administration website or by using Microsoft PowerShell.

+ - In the second text box on the page, select the administrator whom you want to remove. This step doesn't remove the user from the systemΓÇöit merely revokes the user's administrative permissions to the selected service application.

+ - You must be a member of the Administrators group on the server on which you're running the PowerShell cmdlet.

+ For more information about PowerShell permissions, see [Permissions](/powershell/module/sharepoint-server/?view=sharepoint-ps#section3&preserve-view=true) and [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps&preserve-view=true)

+- Authored site elements, which are typically created by web designers, aren't explicitly compiled and are located in a content database. Authored site elements include the following:

+- Developed customizations that aren't packaged as solutions

+Sandboxed solutions are solution packages that site collection administrators can deploy to a single site collection. Sandboxed solutions are stored in the content database that is associated with the site collection to which the solution packages are deployed. They're included in SharePoint Server farm, web application, content database, and site collection backups, but aren't visible in the backup hierarchy and can't be selected or backed up individually.

+ - Administrators group on the server on which you're running the PowerShell cmdlets.

+ > If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For more information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps&preserve-view=true).

+You can't back up only sandboxed solutions. Instead, you must back up the farm, Web application, or content database with which the sandboxed solution is associated.

+You can't back up only authored site elements. Instead, you must back up the farm, Web application, or content database with which the authored site element is associated.

+- Declarative workflows, such as those that were created in SharePoint Designer, are stored in the content database for the site collection to which they're deployed. Backing up the content database protects these workflows.

+ - An XML entry to mark the action as an authorized type is stored in the Web.config file for the Web applications in which it's used.

+- Workflows that aren't yet deployed must be backed up and restored separately. When you're developing a new workflow but haven't yet deployed it to the SharePoint Server farm, make sure that you back up the folder where you store the workflow project files by a file system backup application.

+Changes to the Web.config file that aren't made by using Central Administration or the SharePoint Server APIs and object model should be protected by using a file system backup.

+If third-party products are deployed as solution packages, they're protected by SharePoint Server backup. We recommend that you keep all the original files, distribution media, documentation, and the license and product keys that are required for installation.

+## Back up developed customizations that aren't packaged as solutions in SharePoint Server

+Backing up developed customizations that aren't deployed as solution packages can be a complex process because the customization file locations might not be stored in standardized places and SharePoint Server doesn't automatically back them up.

+- **Concurrent users** - It's most common to measure the concurrency of operations executed on the server farm as the number of distinct users generating requests in a given time frame. The key metrics are the daily average and the concurrent users at peak load.

+- **Total daily requests** - Total daily requests is a good indicator of the overall load the system will need to handle. It's most common to measure all requests except authentication handshake requests (HTTP status 401) over a 24-hour period.

+In estimating the required throughput your farm needs to be able to sustain, begin with estimating the mix of transactions that will be used in your farm. Focus on analyzing the most frequently used transactions that the system will serve, and understand how frequently they'll be used and by how many users. This understanding will help you later when you validate whether the farm can sustain such loads in preproduction testing.

+ - Coauthor interactions.

+ You'll be making some assumptions. For example:

+If you have an existing Office SharePoint Server 2007 solution, you can mine the IIS log files or look to other Web monitoring tools you have to better understand some of the expected behaviors from the existing solution. Otherwise, see the instructions in the section below for more details. If you're not migrating from an existing solution, you should fill out the table using rough estimates. In later steps, you'll need to validate your assumptions and tune the system.

+- How heavily they're using the system.

+- Total number of documents - Other than the data corpus size, it's important to track the overall number of items. The system reacts differently if 100 GB of data is composed of 50 files of 2 GB each versus 100,000 files of 1 KB each. In large deployments, the less stress there is on a single item, document, or area of documents, the better performance will be. Widely distributed content like multiple smaller files across many sites and site collection is easier to serve than a single large document library with large files.

+- **Maximum site collection size** - It's important to identify what's the biggest unit of content that you'll store in SharePoint Server 2013; usually it's an organizational need that prevents you from splitting that unit of content. Average size of all site collections and the estimated total number of site collections are other indicators that will help you identify your preferred data architecture.

+One of the deliverables of [Step 1: Model](capacity-planning.md#step1) is a good understanding of the performance and reliability targets that best fit the needs of your organization. A properly designed SharePoint Server 2013 solution should be able to achieve "four nines" (99.99%) of uptime with subsecond server responsiveness.

+- **Server availability**: Described by the percent of overall uptime of the system. You should track any unexpected downtime and compare the overall availability to the organizational target you set. The targets are commonly described by a number of nines (that's, 99%, 99.9%, 99.99%)

+- **Server spikiness**: Another good server side latency indicator worth tracking is the behavior of the slowest 5% of all requests. Slower requests are usually the requests that hit the system when it's under higher load or even more commonly, requests that are impacted by less frequent activity that occur while users interact with the system; a healthy system is one that has the slowest requests under control as well. The target here's similar to Server Responsiveness, but to achieve subsecond response on server spikiness, you'll need to build the system with numerous spare resources to handle the spikes in load.

+- **System resource utilization**: Other common indicators used to track the health of the system are a collection of system counters that indicate the health of each server in the farm topology. The most frequently used indicators to track are % CPU utilization and Available Memory; however, there are several more counters that can help identify a nonhealthy system; more details can be found in [Step 5: Monitor and Maintain](capacity-planning.md#step5).

+We recommend that you begin this step by determining your architecture and topology. Define how you plan to lay out the different farms and the different services in each farm, and then pick the hardware specifications for each of the individual servers in your design. You can also execute this process by identifying the hardware specifications you're expected to deploy (many organizations are constrained to a certain company standard) and then define your architecture and topology.

+Another thing to consider is using virtualized machines. A SharePoint Server 2013 farm can be deployed using virtual machines. Although virtualization hasn't been found to add any performance benefits, it does provide manageability benefits. Virtualizing SQL Server-based computers isn't recommended, but there may be certain benefits to virtualizing the Web server and application server tiers. For more information, see [Virtualization planning](/previous-versions/office/sharepoint-server-2010/ff607968(v=office.14)) (/previous-versions/office/sharepoint-server-2010/ff607968(v=office.14)).

+In addition to the benefit offered to users, if clients have fast data access through the network, a distributed farm must have fast access for inter-server communication. This is especially true when you distribute services across multiple servers or federate some services to other farms. There's significant traffic in a farm across the web server tier, the application server tier, and the database server tier, and network can easily become a bottleneck under certain conditions like dealing with large files or high loads.

+Disk management's not simply a function of providing sufficient space for your data. You must assess the on-going demand and growth, and make sure that the storage architecture isn't slowing the system down. You should always make sure that you have at least 30 percent additional capacity on each disk, above your highest data requirement estimate, to leave room for future growth. Additionally, in most production environments, disk speed (IOps) is crucial to providing sufficient throughput to satisfy the servers' storage demands. You must estimate the amount of traffic (IOps) the major databases will require in your deployment and allocate enough disks to satisfy that traffic.

+Following are the sub steps for preproduction:

+If you can't meet your capacity and performance targets by scaling your farm hardware or making changes to the topology, you may have to consider revising your solution. For example, if your initial requirements were for a single farm for collaboration, Search and Social, you may have to federate some services such as search to a dedicated services farm, or split the workload across more farms. One alternative is to deploy a dedicated farm for social and another for team collaboration.

+- **Deploying a new SharePoint Server 2013 farm:** The capacity planning exercise should have guided and confirmed plans for a design and deployment of SharePoint Server 2016. In this case, the rollout will be the first broad deployment of SharePoint Server 2013. It will require moving or rebuilding the servers and services that were used during the capacity planning exercises into production. This is the most straight-forward scenario because there aren't any upgrades or modifications needed to an existing farm.

+5. If automatic password change isn't configured for a managed account, enter a numeric value in the **Account Monitoring Process Settings** section that indicates the number of days before password expiration that a notification will be sent to the e-mail address configured in the **Notification E-Mail Address** section.

+If the automatic password change process fails because there's a password mismatch between Active Directory Domain Services (AD DS) and SharePoint Server, the password change process can result in access denial at logon, an account lockout, or AD DS read errors. If any of these issues occur, make sure that your AD DS passwords are configured correctly and that the AD DS account has read access for setup. Use Microsoft PowerShell to fix any password mismatch issues that might occur, and then resume the password change process.

+ - Administrators group on the server on which you're running the PowerShell cmdlets.

+ > If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For more information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps&preserve-view=true).

+If service account provisioning or reprovisioning fails on one or more servers in the farm, check the status of the Timer Service. If the Timer Service has stopped, restart it. Consider using the following Stsadm command to immediately start Timer Service administration jobs: `stsadm -o execadmsvcjobs`

+If restarting the Timer Service doesn't resolve the issue, use PowerShell to repair the managed account on each server in the farm that has experienced a provisioning failure.

+ - Administrators group on the server on which you're running the PowerShell cmdlets.

+ > If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For more information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps&preserve-view=true).

+If the previous procedure doesn't resolve a service account provisioning failure, it's likely because the farm encryption key can't be decrypted. If this is the issue, use PowerShell to update the local server pass phrase to match the pass phrase for the farm.

+ - Administrators group on the server on which you're running the PowerShell cmdlets.

+ > If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For more information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps&preserve-view=true).

+If the password is about to expire, but automatic password change hasn't been configured for this account, use PowerShell to update the account password to a new value that can be chosen by the administrator or automatically generated. After you have updated the account password, make sure that the Timer Service is started and the Administrator Service is enabled on all servers in the farm. Then, the password change can be propagated to all of the servers in the farm.

+ - Administrators group on the server on which you're running the PowerShell cmdlets.

+ > If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For more information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps&preserve-view=true).

+2. Copy the following variable declarations, and paste them into a text editor such as Notepad. Set input values specific to your organization. You'll use these values in step 3. Save the file, and name it Audiences.ps1.

+For additional information about PowerShell scripts and .ps1 files see [Running Windows PowerShell Scripts](/previous-versions/windows/it-pro/windows-powershell-1.0/ee176949(v=technet.10)).

+For more information about how to create audiences, see [AudienceRuleComponent class](/previous-versions/office/sharepoint-server/ms578007(v=office.15)).

+|AlternativeNames | Other DNS domain names or IP addresses that this certificate will be assigned to. Fully Qualified Domain Names (FQDNs) are recommended.|

+|KeySize | Specifies to use the RSA key algorithm for your certificate, and the size of your public and private RSA keys in bits. Larger key sizes provide more cryptographic strength than smaller key sizes, but they're also more computationally expensive and take more time to complete the SSL / TLS connection. Select `2048` if you're unsure, which key size to use. Key sizes larger than `4096` aren't recommended. If neither this parameter nor the `EllipticCurve` parameter is specified, the default key algorithm and key size / elliptic curve of the farm will be used.|

+|EllipticCurve|Specifies to use the elliptic curve cryptography key algorithm for your certificate, and the elliptic curve of your public and private ECC keys. Larger elliptic curves provide more cryptographic strength than smaller elliptic curves, but they're also more computationally expensive and take more time to complete the SSL / TLS connection. Select `nistP256` if you're unsure, which elliptic curve to use. Elliptic curves larger than `nistP384` aren't recommended. If neither this parameter nor the `KeySize` parameter is specified, the default key algorithm and key size / elliptic curve of the farm will be used.|

+|HashAlgorithm|Specifies the hash algorithm of your certificate signature, which your certificate authority will use to verify that your certificate request hasn't been tampered with. Larger hash algorithms provide more cryptographic strength than smaller hash algorithms, but they're also more computationally expensive. Select `SHA256` if you're unsure, which hash algorithm to use. Hash algorithms larger than `SHA384` aren't recommended. If this parameter isn't specified, the default hash algorithm of the farm will be used.|

+|AssignmentCollection| Manages objects for proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the `SPAssignment` object, you can assign objects to a variable and dispose of the objects after they're needed to free up memory. When SPWeb, SPSite, or `SPSiteAdministration` objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter isn't used.|

+|WhatIf|Shows what would happen if the cmdlet runs. The cmdlet isn't run.|

+We recommend [using Secure Store to store your data refresh credentials](data-refresh-using-secure-store.md), but if Secure Store isn't available or if you're working in a test or preproduction environment, this article will show you how to easily configure the account of your choice for scheduled data refresh.

+Before starting, you'll need:

+- Contribute access to the SharePoint document library that you'll be using.

+Anytime you make changes to the data refresh settings page, such as selecting the **Also refresh as soon as possible** check box, you'll need to reenter the password of the data access account.

+If you install SQL Server on a remote computer, that is, on a different computer than the one running MIM, be sure that the policy for the SQL Server service account allows users access to that computer from the network. If access isn't allowed, MIM setup will fail.

+When listing objects by using Metaverse Search, MIM returns results identified by the **displayName** attribute. If the **displayName** attribute isn't populated, the search results are identified by the globally unique identifier (GUID). For more information on how to use metaverse search, see [Using Metaverse Search](/previous-versions/mim/jj572785(v=ws.10))

+Objects that fail to join aren't reevaluated by the Delta Import and Delta Synchronization run profile step and might remain as disconnectors. Running a Delta Synchronization step regularly will reevaluates and processes these disconnectors. For more information on how to run profile steps, see [Configuring Management Agents](/previous-versions/mim/jj590191(v=ws.10)).

+Operations record a history of every management agent run. Each management agent run history is saved in the SQL Server database, and can cause the database to grow over time, affecting performance. The run history can be saved using Operations. For more information on how to use Operations, see [Using Operations](/previous-versions/mim/jj590289(v=ws.10)).

+To control synchronization of single object types in a file-based management agent, create a partition for each object type. For example, to synchronize the object types **mailbox** and **group**, create two partitions in the management agent, and assign **mailbox** to one partition and **group** to the other. Then, create a management agent run profile for each partition. With this configuration, you have one management agent with the flexibility to synchronize one or both of the selected object types. For more information on how to use partitions, see [The Metaverse and the Connector Space](/previous-versions/mim/jj590171(v=ws.10))

+There are many variables that can affect the overall capacity and performance of MIM deployment.

+Performance can be negatively impacted if all the databases in the system are created with a smaller size and set to autogrow especially by small increments. A minimum of 16 GB of RAM for the SQL Servers is required but you'll benefit from more memory. You should have at least 16 CPU cores on the SQL servers but more cores will help overall performance.

+- **MIM Synchronization Service** - although clustering of the MIM Synchronization Service isn't supported, a warm standby server could be deployed to assume the workload of the primary in the event of a failure. However, hardware failure shouldn't be a concern as the MIM Synchronization Service will be running on a virtual machine hosted on multiple physical nodes. Also if there is a software failure, the virtual machine hosting the synchronization server could be quickly recovered from a previous backup or rebuilt from scratch. A down time of this service has no impact on end-user interactions with the solution. It would only delay the fulfillment of all access provisioning and deprovisioning requests. When the service is brought back online those operations would resume with no data loss. The warm standby of the MIM Synchronization Service will be connected to the same SQL Server database as the primary instance and will have to be activated through a script in case the primary instance goes down and can't be restarted in a timely manner. Note that the MIM Management Agent used to synchronize data between the MIM Synchronization Service database and the MIM Service database will have to point to the local MIM Service instance.

+ The design takes into account the best use of the clustered virtual machines without oversubscribing each node and potentially causing both nodes to go down if there is failover.

+ As the databases are hosted on a remote SQL Server the network connection between the MIM Servers and SQL Servers must be 1 Gbit. 100 Mbit network won't provide enough bandwidth and will degrade synchronization performance by 20 to 30 percent.

+If you plan to use the MIM Synchronization service, don't select it. Instead select the **Use SharePoint Active Directory Import** option. There's a known issue with Audience compilation and Manager attribute if the **Enable External Identity Manager** option is selected.

+## Don't switch between synchronization types

+There's no Business Connectivity Services integration to support profile properties in MIM. You can manually configure Connectors to achieve this.

+New user profile properties can be created in SharePoint Servers; however, the mappings aren't created in SharePoint, but within MIM.

+The goal of this step is to create a smoother disaster recovery experience by removing potential points of failure. By matching Authentication Realms, and Database Server ReferenceIDs so they're the same in the disaster recovery farm as in the primary farm, you'll be prepared for recovery. Likewise, it's essential to know which databases must be managed in order to recover successfully.

+Write the ServerRefID to the screen for use when registering the secondary farm Access Services Database Server.

+|Secure Store database <br/> |The Secure Store Service can be used to provide alternate authentication methods for Access apps. The guide referred to earlier doesn't cover doing this, but we'll add the Secure Store database to our strategy for completeness. <br/> |

+For the test environment we discuss in this article, the following databases are recovered from the Primary SQL Server SQL01 to the Secondary SQL Server SQL02 in the DR site.

+Also note that if you're using the secure store in the secondary farm you'll need to generate a new secure store encryption key before you can leverage any Applications registered there.

+Make sure your setup the App Urls in Central Administration on the DR site.

+Recovering the App Management Database doesn't preserve the App Domain even though it does preserve the App Prefix.

+Access Services requires the Contained Databases feature of SQL Server, which supports contained database logins. However, Access Services in SharePoint 2013 and 2016 only partially uses this feature, and so the database logins are stored in the Master DB, just like any other login. The downside to this is that on failover we need to regenerate any missing logins and ensure we set the same password for the account.

+The key elements are: Ensure both server farms are set up with matching Authentication Realms. Ensure Access Services database servers are referenced with the same **ServerReferenceID**. Transfer SQL Logins from Production to DR SQL Servers.

+- **Test results and analysis** that demonstrate and explain trends in throughput, latency, and hardware demand under load at specific scale points.

+Individual SharePoint Server 2013 farms are unique, and each farm has different requirements that depend on hardware, user behavior, the configuration of installed features, and many other factors. Therefore, supplement this guidance with other testing on your own hardware in your own environment. If your planned design and workload resembles the environment described in this article, you can use this article to draw conclusions about how to scale your environment.

+Test results that appear in this article were produced in a test lab, using a workload, dataset, and architecture emulate a production environment under highly controlled conditions. While great care was exercised in designing these tests, the performance characteristics of a test lab are never the same as the behavior of a production environment. These test results don't represent the performance and capacity characteristics of a production farm. Instead, the test results demonstrate observed trends in throughput, latency, and hardware demand, and provide analysis of the observed data that can help you make decisions about how to plan capacity and manage your own farm.

+Here are some specialized terms that you'll encounter in this article.

+- **RPS:** Requests per second, or the number of requests that a farm or server receives in one second. This is a common measurement of server and farm load.

+ Requests differ from page loads. A page contains several components, each of which creates one or more requests when a browser loads the page. Therefore, one page load creates several requests. Typically, authentication checks and events that use insignificant resources aren't counted in RPS measurements.

+4. We scaled out more web servers to the maximum for the scope of testing.

+5. We conducted more testing to compare the performance characteristics of SharePoint Server 2013 and SharePoint Server 2010.

+- The database servers weren't part of a cluster because redundancy wasn't necessary for the purposes of these tests.

+- Search crawl wasn't running during the tests. It might be running in a production environment. To take this into account, we lowered the SQL Server CPU utilization in our definitions of 'Green Zone' and 'Red Zone' to accommodate the resources that a running search crawl would normally consume during testing.

+One physical database server runs the default SQL Server instance that has the SharePoint databases. The logging database isn't tracked in this article.

+### Web server scale-out

+- Even up to the maximum tested scale of ten web servers, the addition of more database servers didn't increase throughput. The bottleneck was confined to web server resources.

+- The average latency at green zone was almost constant throughout the whole test. The number of web servers and throughput didn't affect green zone latency. Red Zone latency data shows an expected trend line. Latency is high at a single web server. A curve between 2 and 10 web servers remains comfortably within Red Zone criteria.

+- When performance testing was conducted for SharePoint Server 2010, the database server became a bottleneck at maximum throughput using four web servers. Because of improvements in caching and database usage characteristics in SharePoint Server 2013, the average load on the database server layer is lower than it was in SharePoint Server 2010, and it wasn't necessary to scale out the database servers during testing.

+To compare SharePoint Server 2013 with SharePoint Server 2010, we used a different test mix from the one outlined in the [Specifications](#Specs) section. This was necessary because some SharePoint Server 2013 features (such as the Distributed Cache Service) and operations weren't available in SharePoint Server 2010.

+- We didn't modify the dataset after the content database upgrade for the SharePoint Server 2013 tests.

+- In general, SharePoint Server 2013 performed better than SharePoint Server 2010 when scaled out to five web servers, but SharePoint Server 2010 results were better at two web servers. Testing against the upgraded SharePoint Server 2013 server farm didn't involve post-upgrade optimizations or take advantage of SharePoint Server 2013 performance improvements such as the Distributed Cache Service or Request Manager. SharePoint Server 2013 test results, therefore, are significantly different from results in a real-world environment.

+description: "Administrator guidance for multitenant hosts in SharePoint Server."

+When considering multi-tenancy, there are two extremes for the implementation model of a multitenant hosting platform:

+The decision to implement a multitenant hosting platform comes down to selecting between these two implementation models. The decision is typically based on the required functional components, and the following service-level related attributes that ordinarily influence the choice of an appropriate implementation model for a multitenant hosting platform.

+These key attributes are important to consider when you make the decisions for selecting the appropriate architecture, implementation, and deployment of a multitenant SharePoint Server 2013 hosting platform. The following diagram shows how these key attributes vary from one implementation model to the other.

+Services can be configured to share data across all tenants or to partition data for each tenant, for example, provide data isolation. Each service can be set up differently. Services can be created in partitioned mode by using Microsoft PowerShell or in unpartitioned mode by using Microsoft PowerShell or Central Administration. Once created, the mode of the Service can't be changed. To achieve partitioning, both the service and the service connection must be deployed in partitioned mode. The service connection is called a proxy in Microsoft PowerShell.

+Not all services can be partitioned. Services that don't store tenant data, such as PowerPoint Automation Services, don't have to be partitioned. These services can be shared across multiple tenants without risk of exposing tenant-specific data.

+In SharePoint, multi-tenancy is tied to site subscriptions. A site subscription is a logical group of site collections that can share settings, features, and service data. Site collections for each tenant are brought together with a subscription ID. The subscription ID is used to map features, services, and sites to tenants and also to partition service data according to tenant. The Subscription Settings service keeps track of multitenant services and subscription IDs.

+Here's how it works:

+1. Farm administrators deploy services to the farm. This includes the Subscription Settings service. Service applications can be either deployed as partitioned where data is isolated for each tenant, or unpartitioned where data is shared across all tenants. Some services don't store tenant data and are shared across all tenants without a partition.

+2. Farm administrators deploy a Tenant Administration site for each tenant by using Microsoft PowerShell. The Tenant Administration site is associated with a subscription ID. Administrators can deploy other site collections for each tenant. Each site collection is tied to the subscription ID of the tenant.

+Data partitioning plays a large role in deciding which approach to take for a SharePoint deployment then a physical partition is required. The solution is to have a farm and even a single Identity Provider per tenant. But if some data can be shared we can then move towards sharing elements of the infrastructure across multiple tenants, database servers, some SharePoint services, and the farm.

+Depending upon authentication requirements, custom code may be required. When using Windows Authentication, code isn't required and the SharePoint people picker is fully functional. Security Assertion Markup Language (SAML) or Forms Based authentication (FBA) require a custom claims provider that implements search and validates procedures.

+For more information about SAML authentication and FBA authentication in SharePoint Server 2013, see [Configure SAML-based claims authentication with AD FS in SharePoint Server](../security-for-sharepoint-server/security-for-sharepoint-server.md) and [Configure forms-based authentication for a claims-based web application in SharePoint Server](../security-for-sharepoint-server/security-for-sharepoint-server.md).

+Depending on the topology, the administrator experience can be different:

+- In a one tenant per farm approach there are no in-product possibilities to separate the Service administration experience from the tenant administration experience. In other words, there's no way to delegate specific functionalities of the SharePoint Central Administration website to the tenant administrator to provision new site collections. You also can't configure a default Search Center for the tenant without permitting any Farm Topology change or Service configuration change.

+- In a multiple tenants per farm approach, the product provides an in-product tenant administration console. In this approach, the Tenant Administration Site Collection lets tenant administrators perform specific functionalities. In the previous configuration, there are specific functionalities in the Central Administration that can't be performed without causing potential unexpected results. For example, don't create site collections in Central Administration.

+The collection of features and services that enable multi-tenancy with SharePoint Server 2013 comprise a base platform that is typically extended to provide the end-to-end service offering by hosting organizations. Many key operational service management aspects of SharePoint Server 2013 behave differently when they use multi-tenancy, and therefore require careful consideration. These aspects vary between different organizations based on service levels and operational capabilities. Hosting partners should guarantee that satisfactory planning for the required more customization, either with custom solutions or Microsoft PowerShell is in place as soon as possible, to meet customer expectations. Examples in this space include:

+Along with the previous considerations, tenant provisioning and deprovisioning processes and scripts have to account for each service application that stores tenant data. For some service applications, all the management of tenant data is moved to elements of the tenant administration site, whereas with some, a combination of farm-level and tenant-level administration is required.

+- *Recommendations* are based on how other visitors have interacted with your website. For example, on a product page, you can display "People who viewed this product also viewed *\<other products\>. "

+To help explain, we'll use examples from a fictitious company called Contoso. Here's what the website will look like when it's finished.

+The scenario in this set of articles draws heavily upon the concepts, feature descriptions, and procedures introduced in the [How to set up a product-centric website in SharePoint Server](how-to-set-up-a-product-centric-website.md) series. We recommend reading it first, as it will make things easier to understand.

+|Pros <br/> |1. Flexibility allows for customized import. <br/> 2. Can be customized for bidirectional flow. <br/> 3. Imports user profile photos automatically. <br/> 4. Supports non-Active Directory LDAP sources. <br/> 5. Multi-forest scenarios are supported. <br/> |1. Fast and performant. <br/> 2. Known to be reliable (used by Microsoft 365). <br/> 3. Configurable inside of Central Administration. (Less complex.) <br/> |

+|Cons <br/> |1. A separate MIM server is recommended for use with your SharePoint farm. <br/> 2. The more customized the more complex the architecture, deployment, and management. <br/> |1. Import is unidirectional (changes go from Active Directory to SharePoint Server Profile). <br/> 2. Import from a single Active Directory forest only. <br/> 3. Doesn't import user photos. <br/> 4. Supports Active Directory LDAP only. <br/> 5. Multi-forest scenarios aren't supported. <br/> |

+If you choose MIM, there are some **prerequisites** of which you should be aware. You'll need:

+1. First, download, and install MIM to the server where you want to install.

+2. Extract the .zip file and double-click Setup.exe. (Setup.exe is found in the SynchronizationService folder of the MIM media.)

+7. The next step (firewall rules) is optional. We recommend you don't check the firewall rule checkbox.

+10. MIM installation should complete. You should log off and back on to your server again to ensure the MIM cache is updated.

+11. Once you log on again, ensure the MIM service is running on the server by going to Services (or Start or Windows key> **Run** > services.msc) and then locating the **Forefront Identity Manager Synchronization Service**. No mistake. The service name hasn't changed!

+The **Action** column displays one of three values depending on the type of service it's and whether it's enabled in the farm: **Manage Service application**, **Disable Auto Provision**, and **Enable Auto Provision**.

+The **Compliant** column displays whether the service is in compliance on every server in the farm. If this service isn't in compliance on one or more servers, a **Fix** link will be provided. Click this link to automatically reconfigure the service instances of this service to match the expected configuration.

+The **Compliant** column has been added to the page. It displays whether the service instance is in compliance on this server. If this service instance isn't in compliance on this server, a Fix link will be provided. Click this link to automatically reconfigure the service instance on this server to match the expected configuration.

+A new health analyzer rule has been created to ensure that your servers are operating in their optimal MinRole configuration. The **Server role configuration isn't correct** rule runs every night at midnight on each server in your farm. It scans all service instances on the server to detect if any aren't in compliance. If any service instance isn't in compliance, the health rule will automatically reconfigure it to match the expected configuration. No manual intervention by the SharePoint farm administrator is required.

+The automatic repair functionality of the health rule can be disabled by the SharePoint farm administrator while still allowing the health rule to run. If the health rule detects that a server isn't in compliance and the automatic repair functionality is disabled, it will generate a health report in Central Administration. The health report will identify which servers aren't in compliance, offer the ability to automatically repair the servers, and provide instructions on how to manually repair the servers.

+The SharePoint farm administrator can control the health rule schedule, changing it to run more frequently or less frequently or disabling it so that it's never scheduled. It can also run on demand.

+If you're a SharePoint developer intending to create an application with services, it's recommended that you assign each type of service instance to one or more server roles supported by MinRole:

+You can use the SharePoint Central Administration website to monitor and manage licenses for apps for SharePoint. Licenses for apps for SharePoint are digital sets of verifiable information that state the user rights for an app for SharePoint. Apps that are distributed through the SharePoint Store are the only apps that have built-in licenses that SharePoint Server recognizes.

+Here are the basics of what SharePoint Server does and doesn't provide for apps for SharePoint licensing:

+- SharePoint Server doesn't enforce app for SharePoint licenses.

+- All apps for SharePoint licenses are bound to a specific SharePoint Server deployment but can be transferred to a different SharePoint Server deployment three times.

+A farm administrator or a license manager can check the licenses for all apps for SharePoint on the App Licenses page. It's important to track the number of licenses that are available for each app for SharePoint so that users don't exceed this number. An administrator can assign more users to an app for SharePoint license, purchase more licenses for an app, and also add managers to a license.

+ The app for SharePoint details shows any changes the administrator has made.

+Access Services in SharePoint Server 2013 is service applications that enable you to share two types of Access 2013 solutions on the web.

+Access apps for SharePoint are a new type of database that you build in Access 2013, then use and share with others as an app for SharePoint in a web browser. To build an Access app, you select the type of data that you want to track (contacts, tasks, projects, and so on). Access creates the database structure and various views that let you add and edit data. Navigation and basic commands are built in, so you can start to use the app right away. Once the Access app is running, it's a straightforward task to customize and enhance the Access app over time.

+By default, you can't create a web database by using Access 2013. However, you can still view and edit a web database that was previously created by using Access 2010 and SharePoint Server 2010, and you can republish it to SharePoint Server 2016.

+There's no way to automatically convert a web database to an Access app. If you want to manually convert a web database to an Access app to take advantage of new functionality and features, you can do the following:

+This article describes how to test the performance of SharePoint Server 2013. The testing and optimization stage is a critical component of effective capacity management. You should test new architectures before you deploy them to production and you should conduct acceptance testing with following monitoring best practices in order to ensure the architectures you design achieve the performance and capacity targets. This allows you to identify and optimize potential bottlenecks before they impact users in a live deployment. If you're upgrading from an Office SharePoint Server 2007 environment and plan to make architectural changes, or are estimating user load of the new SharePoint Server 2013 features, then testing important to make sure your new SharePoint Server 2013-based environment will meet performance and capacity targets.

+These are the recommended sub steps you should follow for preproduction:

+- If you have custom code or custom component, it's important that you test the performance of those components in isolation first to validate their performance and stability. After they're stable, you should test the system with those components installed and compare performance to the farm without them installed. Custom components are often a major culprit of performance and reliability problems in production systems.

+- Understand how to measure for your testing goal. If you're interested in measuring the throughput capacity of your farm, for example, you'll want to measure the RPS and page latency. If you're measuring for search performance, then you'll want to measure crawl time and document indexing rates. If your testing objective is well understood, that will help you clearly define what key performance indicators you need to validate in order to complete your tests.

+- **Authentication**: Decide whether the farm will use Active Directory Domain Services (AD DS), forms-based authentication (and if so with what directory), claims-based authentication, etc. Regardless of which directory you're using, how many users do you need in your test environment and how are you going to create them? How many groups or roles are you going to need and how will you create and populate them? You also need to ensure that you have enough resources allocated to your authentication services that they don't become a bottleneck during testing.

+- **DNS**: Know what the namespaces are that you'll need during your testing. Identify which servers will be responding to those requests and make sure you've included a plan that has what IP addresses will be used by which servers, and what DNS entries you'll need to create.

+- **Load balancing**: Assuming you're using more than one server (which you normally would or you likely wouldn't have enough load to warrant load testing), you'll need some kind of load balancer solution. That could be a hardware load balancing device, or you could use software load balancing like Windows NLB. Figure out what you will use and write down all of the configuration information you'll need to get it set up quickly and efficiently. Another thing to remember is that load test agents typically try to resolve the address to a URL only once every 30 minutes. That means that you shouldn't use a local hosts file or round robin DNS for load balancing because the test agents will likely end up going to the same server for every single request, instead of balancing around all available servers.

+- **Test servers**: When you plan your test environment, you not only need to plan for the servers for the SharePoint Server 2013 farm, you also need to plan for the machines needed to execute the tests. Typically that will include three servers at a minimum; more may be necessary. If you're using Visual Studio Team System (Team Test Load Agent) to do the testing, one machine will be used as the load test controller. There are generally two or more machines that are used as load test agents. The agents are the machines that take the instructions from the test controller about what to test and issue the requests to the SharePoint Server 2013 farm. The test results themselves are stored on a SQL Server-based computer. You shouldn't use the same SQL Server-based computer that is used for the SharePoint Server 2016 farm, because writing the test data will skew the available SQL Server resources for the SharePoint Server 2013 farm. You also need to monitor your test servers when running your tests, the same way as you would monitor the servers in the SharePoint Server 2013 farm, or domain controllers, etc. to make sure that the test results are representative of the farm you're setting up. Sometimes the load agents or controller can become the bottleneck themselves. If that happens, then the throughput, you see in your test is typically not the maximum farm can support.

+- **Dataset validation**: As you decide what content you're going to run tests against, remember that in the best case scenario you'll use data from an existing production system. For example, you can back up your content databases from a production farm and restore them into your test environment, then attach the databases to bring the content into the farm. Anytime you run tests against made up or sample data, you run the risk of having your results skewed because of differences in your content corpus.

+- Determine how many SharePoint groups and/or permission levels you're going to need, and how you're going to associate users with them.

+- Determine whether you need more search content sources, and what you will need to create them. If you won't need to create them, determine whether you'll have network access to be able to crawl them.

+- Determine whether you have enough sample data - documents, lists, list items, etc. If not, create a plan for how you'll create this content.

+After the test environment is functional, it's time to create and fine-tune the tests that will be used to measure the performance capacity of the farm. This section will at times make references specifically to Visual Studio Team System (Team Test Load Agent), but many of the concepts are applicable irrespective of which load test tool you use. For more information about testing tools available for Azure DevOps (formerly VSTS), see [DevOps tools overview for Azure DevOps](/azure/devops/user-guide/devops-alm-overview).

+You can also use the SharePoint Load Test Kit (LTK) with VSTS for load testing of SharePoint 2010 farms. The Load Test Kit generates a Visual Studio Team System 2008 load test based on Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 IIS logs. The VSTS load test can be used to generate synthetic load against SharePoint Foundation 2010 or SharePoint Server 2010 as part of a capacity planning exercise or a preupgrade stress test.

+A key criterion to the success of the tests is to be able to effectively simulate a realistic workload by generating requests across a wide range of the test site data, just as users would access a wide range of content in a production SharePoint Server 2013 farm. In order to do that, you'll typically need to construct your tests such that they're data driven. Rather than creating hundreds of individual tests that are hard-coded to access a specific page, you should use just a few tests that use data sources containing the URLs for those items to dynamically access that set of pages.

+ In Visual Studio Team System (Team Test Load Agent), a data source can come in various formats, but a CSV file format is often easiest to manage and transport between development and test environments. Keep in mind that creating CSV files with that content might require the creation of custom tools to enumerate the SharePoint Server 2013-based environment and record the various URLs being used.

+- Populating SharePoint groups and permission levels with users and Active Directory groups (or roles if you're using forms based authentication)

+- Record simple web tests as a starting point. Those tests will have hard-coded values in them for parameters like URL, IDs, etc. Replace those hard-coded values with links from your CSV files. Data binding those values in Visual Studio Team System (Team Test Load Agent) is easy.

+- Always have validation rules for your test. For example, when requesting a page, if an error occurs you'll often get the error.aspx page in response. From a web test perspective, it appears as just another positive response, because you get an HTTP status code of 200 (successful) in the load test results. Obviously an error has occurred though so that should be tracked differently. Creating one or more validation rules allows you to trap when certain text is sent as a response so that the validation fails and the request is marked as a failure. For example, in Visual Studio Team System (Team Test Load Agent) a simple validation rule might be a ResponseUrl validation - it records a failure if the page that is rendered after redirects isn't the same response page that was recorded in the test. You could also add a FindText rule that will record a failure if it finds the word "access denied," for example, in the response.

+- Use multiple users in different roles for tests. Certain behaviors such as output caching work differently depending on the rights of the current user. For example, a site collection administrator or an authenticated user with approval or authoring rights won't get cached results because we always want them to see the most current version of content. Anonymous users, however, will get the cached content. You need to make sure that your test users are in a mix of these roles that approximately matches the mix of users in the production environment. For example, in production there are probably only two or three site collection administrators, so you shouldn't create tests where 10% of the page requests are made by user accounts that are site collection administrators over the test content.

+ - These items don't typically come from SQL Server in a SharePoint Server 2013-based environment. With BLOB caching turned on, they're instead served by the Web servers so they don't generate SQL Server load.

+If you regularly have a high percentage of first time users to your site, or you have disabled browser caching, or for some reason you don't intend to use the blob cache, then it may make sense to enable parsing dependent requests in your tests. However this is really the exception and not the rule of thumb for most implementations. Be aware that if you do turn this on it can significantly inflate the RPS numbers reported by the test controller. These requests are served so quickly it may mislead you into thinking that there's more capacity available in the farm than there actually is.

+- In most cases a web test should only contain a single request. It's easier to fine-tune and troubleshoot your testing harness and individual requests if the test only contains a single request. Web tests will typically need to contain multiple requests if the operation it's simulating is composed of multiple requests. For example, to test this set of actions you'll need a test with multiple step: checking out a document, editing it, checking it in and publishing it. It also requires reserving state between the steps - for example, the same user account should be used to check it out, make the edits, and check it back in. Those multi-step operations that require state to be carried forward between each step are best served by multiple requests in a single web test.

+- Consider the impact of other resource intensive operations and decide whether they should be occurring during the load test. For example, operations like backup and restore are not generally done during a load test. A full search crawl may not be usually run during a load test, whereas an incremental crawl may be normal. You need to consider how those tasks will be scheduled in production - will they be running at peak load times? If not, then they should probably be excluded during load testing, when you're trying to determine the maximum steady state load you can support for peak traffic.

+- Don't use think times. Think times are a feature of Visual Studio Team System (Team Test Load Agent) that allow you to simulate the time that users pause between clicks on a page. For example a typical user might load a page, spend three minutes reading it, then click a link on the page to visit another site. Trying to model this in a test environment is nearly impossible to do correctly, and effectively doesn't add value to the test results. It's difficult to model because most organizations don't have a way to monitor different users and the time they spend between clicks on different types of SharePoint sites (like publishing versus search versus collaboration, etc.). It also doesn't really add value because even though a user may pause between page requests, the SharePoint Server 2013-based servers don't. They just get a steady stream of requests that may have peaks and valleys over time, but they aren't waiting idly as each user pauses between clicking links on a page.

+- Understand the difference between users and requests. Visual Studio Team System (Team Test Load Agent) has load pattern where it asks you to enter the number of users to simulate. This doesn't have anything to do with application users, it's just how many threads are going to be used on the load test agents to generate requests. A common mistake is thinking that if the deployment will have 5,000 users, for example, then 5,000 is the number that should be used in Visual Studio Team System (Team Test Load Agent) - it isn't! That's one of the many reasons why when estimating capacity planning requirements, the usage requirements should be based on number of requests per second and not number of users. In a Visual Studio Team System (Team Test Load Agent) load test, you'll find that you can often generate hundreds of requests per second using only 50 to 75 load test "users".

+- Use a constant load pattern for the most reliable and reproducible test results. In Visual Studio Team System (Team Test Load Agent), you have the option of basing load on a constant number of users (threads, as explained in the previous point), a stepped up load pattern of users, or a goal based usage test. A stepped load pattern is when you start with a lower number of users and then "step up" adding additional users every few minutes. A goal based usage test is when you establish a threshold for a certain diagnostic counter, like CPU utilization, and test attempts to drive the load to keep that counter between a minimum and maximum threshold that you define for it. However, if you're just trying to determine the maximum throughput your SharePoint Server 2013 farm can sustain during peak load, it's more effective and accurate to just pick a constant load pattern. That allows you to more easily identify how much load the system can take before starting to regularly exceed the thresholds that should be maintained in a healthy farm.

+Each time you run a load test remember that it's changing data in the database. Whether that's uploading documents, editing list items, or just recording activity in the usage database, there will be data that is written to SQL Server. To ensure a consistent and legitimate set of test results from each load test, you should have a backup available before you run the first load test. After each load test is complete the backup should be used to restore the content back to the way, it was before the test was started.

+This article takes you through five questions that you must answer before you can design your Business Connectivity Services solution. Be sure to collect all this information and communicate it to all the key stakeholders to review and approve. When you do this, you'll help ensure that everyone involved has the same understanding of the needs of the project and how the solution will work.

+You'll need to know who has daily administrative responsibility over the external data source. This is the group that you'll need to work with to help set up connectivity to the external data. They'll be able to tell you how the data is made available for external consumption, how it's secured, and so on. You might need them to create credentials in the external system for you to use. Be prepared to answer their questions on the impact of your Business Connectivity Services solution on their data and their external system.

+You also need to consider where the external data source is in relation to the network that Business Connectivity Services and your users will be on. To help you figure this out, draw a diagram of the three components on your network and see where they lie. For example, you can see whether they're all on your internal network and inside your firewall. Or, you could see that the Business Connectivity Services infrastructure and the external data source are separated by a firewall or boundary network and that they are on completely separate networks. Here are some basic rules that you can use to guide your design:

+Business Connectivity Services solutions can connect to an external data source through OData, SQL Server, Windows Communication Foundation (WCF) service, and .NET Assemblies. You need to know (and you can find this out from the external system administrators) how the data is surfaced for external consumption. How the external data is surfaced determines what development tools you'll use to create the external content type. The following table shows you which tools to use based on the external data source.

+Business Connectivity Services handles all authentications for communications between itself and the external system. Basically, Business Connectivity Services presents the external system with information that allows the external system to authenticate (determine whether you're who you say you are) the request and then authorize access to data in the external system. Business Connectivity Services supports many types of authentication.

+For your Business Connectivity Services solution design, you have to know what authentication mechanism the external system requires. This way, you'll know how to configure Business Connectivity Services so that it presents the authentication information in the manner that the external system requires. Business Connectivity Services supports three authentication models:

+- **Credentials-based authentication** In credentials-based authentication models, credentials are passed from Business Connectivity Services to the external system. Credentials are a combination of a user name and some form of password. Business Connectivity Services has many ways of doing this, including passing the credentials of the user who is logged on, passing the credentials of the service that is making the request, or mapping the credentials of the user who is logged on to a different set of credentials that the external system recognizes.

+- **Claims-based authentication** In some authentication scenarios, the external system won't accept credentials directly from Business Connectivity Services. However, the external system will accept them from a third-party authentication service that it trusts. The third-party authentication service (a security token provider) accepts a grouping of information (known as assertions) about the requestor. The whole grouping is known as a claim, and a claim can contain more info about the requestor than just the user name and password. For example, a claim can contain metadata about the requestor, such as the requestor's email address or the security groups to which the requestor belongs. The third-party authentication service performs the authentication of the requestor based on the assertions in the claim and creates a security token for the requestor to use. The requestor (Business Connectivity Services) then presents the security token to the external system, and the external system looks to see what data the requestor has been authorized to access.

+- **Custom authentication** If the external system that you're working with doesn't support credentials-based or claims-based authentication, then you'll have to develop, test, and implement a custom solution that takes the credentials that Business Connectivity Services can produce and translates them into a format that the external system will accept. You can implement a custom authentication solution for OData data sources that are secured either by OAuth or a custom ASP.NET HTTP module and are on premises.

+How users access the data affects how you'll scope the external content type that Business Connectivity Services uses to access the external data. If your Business Connectivity Services solution requires an apps for Office and SharePoint application, then the external content type must be scoped to that application. If your Business Connectivity Services solution won't use apps for Office and SharePoint to access external data, then the external content type must be scoped to the Business Data Connectivity service application.

+In every Business Connectivity Services solution, you must plan who will have which permissions on which objects. This is how you both restrict and grant access to the solution to the appropriate users in the appropriate way. You'll have to work with the external system administrator and the SharePoint Server farm administrators, site collection administrators, and site administrators to configure permissions. At the most fundamental level however, here is what you must consider during your planning.

+There are also four main aspects to every Business Connectivity Services solution for which you'll manage permissions:

+- **External system** Every external system will have a method for performing authentication and authorization. (For more information, see [How is the data secured?](plan-a-business-connectivity-services-solution.md#section3) earlier in this article.) You need to work with the external system administrator to identify how to grant access to the solution users according to the principle of least privileges. In general, you'll map a group of users from the Business Connectivity Services side to a single account on the external system side and use the single external system account to restrict access. Another way is to do a 1:1 mapping between individual accounts on each system. In either case, unless the external system can directly accept the credentials with which the user authenticates to SharePoint Server, you'll need to use the [Secure Store Service](/previous-versions/office/sharepoint-server-2010/ee806889(v=office.14)). For more in-depth information about the authentication models that Business Connectivity Services supports, see [Business Connectivity Services security overview (SharePoint 2010)](/previous-versions/office/sharepoint-server-2010/ee661743(v=office.14)).

+- **The development environment** When you're developing a Business Connectivity Services solution, including the external content type, and any apps for SharePoint and connection settings objects, it's a best practice to use a development environment that is separate from your production environment. In the development environment, you can grant higher levels of permissions to the developers than you would usually do in your production environment.

+- **The user environment** All external data will be accessed through external lists, external data columns, Business Data Web Parts, apps for SharePoint, or Office. For apps for SharePoint, you can choose to let the app for Office and SharePoint enforce permissions. In this case, if the users can access the app for Office and SharePoint, then they can access all the external data that is surfaced in the app for Office and SharePoint. You'll have to work with site and site collection administrators to plan and implement permissions to the external data in your solution.

+- You'll need SSL Certificates If you're using SSL to help secure traffic. You must create a wildcard certificate to use for all app URLs.

+- Each app for SharePoint that is installed creates a subweb under the site on which it's installed with its own URL. This means that environments that contain many apps for SharePoint will have many additional subwebs. Be sure to consider this when planning for capacity for your farm.

+Additionally, using apps for SharePoint requires a separate DNS domain configuration (discussed below), and the Subscription Settings and App Management service applications. We cover how to configure the separate app domain and the service applications in the [apps for SharePoint configuration article](configure-an-environment-for-apps-for-sharepoint.md).

+With apps for SharePoint, apps are deployed to their own web site in a special, isolated domain name, instead of in the same domain name as your farm. Processes run under that domain name and don't affect the SharePoint sites. This difference in domain names provides a layer of isolation for the apps.

+Each app for SharePoint has a unique URL, which is made up of the app domain plus a prefix and an Apphash. The format is as follows: prefix-Apphash.domain.com. The Apphash is an arbitrarily assigned unique identifier for each app for SharePoint. These URLs are generated automatically depending on the settings that you specify. You don't have to create or manage these URLs separately; instead you configure a wildcard entry in DNS to provide the URLs for all apps.

+When you choose the domain name and prefix to use for your environment, consider the following:

+ For security reasons, we highly recommend that you not use a subdomain of the root domain name that hosts SharePoint Server or other applications. For example, if the SharePoint sites are at Contoso.com, don't use Apps.Contoso.com. Instead use a unique name such as Contoso-Apps.com. This is because other applications that run under that host name might contain sensitive information that is stored in cookies that might not be protected.

+ For security reasons, we recommend that you configure the app domain to be in either the Internet or Restricted sites security zone in Internet Explorer options, and not in the Intranet zone or Trusted sites zone. Internet Explorer security settings for the Intranet zone or Trusted sites zone don't provide a sufficient level of isolation of apps from user data in SharePoint sites.

+ Prefixes must be fewer than 48 characters and cannot contain special characters or dashes.

+As a best practice, we recommend that you use a single web application that uses host-named site collections (host headers) instead of multiple web applications that use path-named site collections in your environment. When you use multiple web applications and path-named site collections, you might have to complete additional configuration steps to guarantee that requests for apps for SharePoint are routed to the correct web application.

+SharePoint Server doesn't enforce app licenses. Developers who build apps must add code that retrieves license information and then addresses users. SharePoint Server provides the storage and together with SharePoint Store web services the app license renewal. SharePoint Store handles payments for the licenses, issues the correct licenses, and provides the process to verify license integrity. Note that licensing only works for apps that are distributed through the SharePoint Store. Apps that you purchase from another source and apps that you develop internally must implement their own licensing mechanisms. SharePoint Server supports the following app licenses formats:

+If you're planning to build a publishing site based on SharePoint Server, you have probably already made some decisions about what kind of sites are needed, and how you want them distributed. For example, if you're building an Internet business site, you probably already know how many public-facing sites you require for each region or brand. If you're building an intranet site for your company, you have probably already determined how many internal sites you require for each division or group. It isn't necessary to have a detailed plan of the physical architecture at this stage in the project. However, when you plan to set up a publishing site, it's important to consider if you have to plan for sites to be inside or outside a firewall, and if some sites will allow anonymous users. For more information about how to plan for sites, see [Plan sites and site collections in SharePoint Server](../sites/plan-sites-and-site-collections.md).

+## Determine what type of content you'll have on each site

+What type of content do you plan to publish on the site? Is the site an intranet knowledge base that will have only Pages library content? Or is the site an Internet business site that will display lists of products and descriptions, together with Pages library content? If you plan to use cross-site publishing, how many catalogs do you have? Are any catalogs in external data sources? Will you import catalogs into the site, or will you create content directly in SharePoint Server? Knowing what type of content you have will help you determine what publishing method you'll use later in this article.

+Does your site require that content be provided in more than one language, or to more than one locale? Even if you currently plan to only create and publish content in a single language, you should carefully consider whether that business requirement might change in the future. If there's a chance you might eventually want to use variations on the site, you should plan for using variations now. By setting up your site structure now in preparation for using variations, you'll save yourself and your organization time and resources in the future. If you have to change the site structure when you switch to using variations later, it's often more difficult and can affect the URLs that you planned for your sites. For more information about variations, see [Variations overview in SharePoint Server](variations-overview.md). For information about how to plan variations, see [Plan for variations in SharePoint Server](plan-for-variations.md).

+- **Author-in-place** Uses a single site collection to author content and make it available to readers of your site. If you plan to publish only Pages library content, and you don't have to author on more than one site, or publish to more than one site, and you don't have a business need to author separately from your production environment, you should use author-in-place. If you must publish multilingual content, you can still use variations to make content available to sites in multiple languages or regions. Author-in-place is available in both SharePoint Server and SharePoint in Microsoft 365.

+- Do you have multiple site collections represented, on either the authoring or publishing sideΓÇöfor example, n:1 or 1:n?

+Although cross-site publishing is the recommended method to use for making content available to multiple sites, it might not be the right method for your publishing solution. You shouldn't use cross-site publishing if you don't plan to use variations with unique URLs, or publish to multiple sites, and you want to author content on the same site collection in which it's published. Use author-in-place instead.

+- [Plan for variations in SharePoint Server](plan-for-variations.md) provides information about important items that you should consider when you're using variations in publishing sites, and it describes the tasks that are involved in planning a solution that uses variations in SharePoint Server.

+Profile synchronization (also known as "profile sync") allows you to create user profiles by importing information from other systems that are used in your organization. Before you read this article, you should understand the concepts introduced in the article [Overview of profile synchronization in SharePoint Server 2013](profile-synchronization-in-sharepoint-server-2013.md). Profile synchronization is also used in server-to-server authentication that enables servers to access and request resources from one another server on behalf of users. For more information, see [Server-to-server authentication and user profiles in SharePoint Server](../security-for-sharepoint-server/server-to-server-authentication-and-user-profiles.md).

+This article doesn't describe how to implement your plan. That information is covered in the article [Synchronize user and group profiles in SharePoint Server 2013](configure-profile-synchronization.md).

+As the first step towards planning for profile synchronization, you'll identify synchronization connections, and collect information that you'll need when you create the connection. If you'll need any external content types, you'll document the requirements for those external content types, provide the requirements to a developer, and receive the details that you'll use to specify a synchronization connection to the business system.

+Each property in a user's profile can come from an external system. There are two types of external systems: directory services and business systems. Throughout this article, the phrase business system is used to mean an external system that isn't a directory service. SAP, Siebel, SQL Server, and custom applications are all examples of business systems.

+In SharePoint Server 2013, a synchronization connection is a way to obtain user profile information from an external system. To import profiles from one of the supported directory services, you create a synchronization connection to the directory service. To import additional profile properties from a business system, you create an external content type to bring the data from the business system into SharePoint Server 2013, and then create a synchronization connection to the external content type. The following sections explain how to collect the information that you'll need about each synchronization connection.

+Each user who you want to have a profile in SharePoint Server 2013 must have an identity in a directory service. (If users aren't represented in a directory service, you can't synchronize user profiles.) Identify which directory services contain information about these users. Unless you can access the directory service yourself, you should also identify an administrator of the directory service. You'll need this person's help to collect some information that will be needed to create synchronization connections.

+|Authentication provider <br/> |All <br/> |If forms-based authentication or claims-based authentication will be used, fill in the name of the trusted provider. The systems architect should be able to provide this information. An authentication provider isn't needed for Windows authentication. <br/> |

+For example, assume that temporary employees in your organization are given Active Directory accounts that begin with "T-". You want to synchronize profiles for all permanent (non-temporary) users whose accounts aren't disabled. You could create a filter that uses the clauses in the following table.

+To import properties from a business system, you'll need an external content type that brings the property value from the external system into SharePoint Server 2013. This article doesn't cover how to create an external content type. That task is usually done by a developer. This article describes the data that you must collect and give to the developer, and tells you what to do with the information that you receive. For developer information, see [External content types in SharePoint 2013](/sharepoint/dev/general-development/external-content-types-in-sharepoint).

+When you synchronize profile information, in addition to importing profile properties from external systems, you can also write data back to a directory service. You can't write data back to a business system. To indicate that SharePoint Server 2013 should export a user profile property, you map the property, and set the direction of the mapping to **Export**. Each property can only be mapped in one direction. You can't both import and export the same user profile property. The data that is exported overwrites any values that might already be present in the directory service. This is true for multivalued properties alsoΓÇöthe exported value isn't appended to the existing values, it overwrites them.

+If you synchronize groups in addition to users, SharePoint Server 2013 imports information about the groups and about which users are members of the groups. Synchronizing a group doesn't create a profile for the group, and causes no additional user profiles to be created. In SharePoint Server 2013, groups are only used to create audiences and to display which memberships a visitor has in common with the person whose My Site the person is visiting.

+ The Replicate Directory Changes permission allows an account to query for the changes in the directory. This permission doesn't allow an account to make any changes in the directory.

+- To perform incremental synchronization, the synchronization account must also have Read, Compare, and Search permissions to the change log (cn=changelog). If the change log doesn't exist, you must create it before synchronizing.

+Search-driven pages are pages that use search technology to dynamically show content. This article describes features that you'll use when you set up search-driven pages, such as managed properties, refiners, result sources, and recommendations, and what you must consider when you set up and use these features.

+The default content source is Local SharePoint sites. You can use this content source to crawl all content within the web application. However, we recommend that you create separate content sources for libraries or lists that you share as catalogs. When you set up a content source for libraries or lists that are shared as catalogs, we recommend that you select **Enable Continuous Crawl** when specifying the crawl schedules. A continuous crawl starts at set intervals, which enables the search system to crawl the content and quickly add any changed content to the index. The default crawl interval for continuous crawl is 15 minutes, but you can set shorter or longer intervals. Enabling continuous crawl also means that a site administrator won't have to wait for the search service application administrator to manually start a crawl in order to update the search index with the latest changes from a catalog.

+There are two types of refiners: stand alone and for faceted navigation. You can use just one type on the site, or a combination of both. The structure of the content and what kind of navigation you use on the site will determine the type of refiners that you should choose.

+- Stand-alone refiners are used in scenarios where you have unstructured content. Within this content, you can identify several managed properties that can be used as refiners across all content. However, you don't want the refiners to change depending on a term in a term set. For example, in an intranet scenario, you can add stand-alone refiners to a Search Center page. These stand-alone refiners are typically managed properties that apply to most items in the intranet, such as Author and Date.

+- Refiners for faceted navigation are used in scenarios where you have structured content, such as catalog content. This content is tied to a term set, and you want to have different refiners for different terms. For example, in an Internet business scenario where a product catalog of electronic products is shown, a term set is used to categorize the different productsΓÇöfor example, Computers or Cameras. After you enable the managed properties Screen Size and Megapixels as refiners, you can configure faceted navigation so that Screen Size appears as a refiner for Computers, and Megapixels appears as a refiner for Cameras. This means that you can guide users to content that is relevant for a specific category. This makes it easier and faster to browse through catalog content.

+When using refiners for faceted navigation, it's especially important that you identify refiners that represent information that users will find useful when they browse through a catalog. You configure refiners in Term Store Management. You can set refiners for a specific term set, you can configure refiners to apply to all terms in a term set, or you can set specific refiners for a specific term. Consider the following:

+- Which managed properties represent information that is unique for only a subset of my catalog items?

+Adding many refiners to your page may increase the time to process a query. For more information, see [Estimate capacity and performance for Web Content Management (SharePoint Server 2013)](web-content-management-capacity-and-performance.md)

+Result sources narrow the scope of search results that are retrieved. SharePoint Server 2016 provides many predefined result sources. Many of the predefined result sources have a corresponding Web Part where the result source is specified as part of the query. For example, the result source Local Video Results is set as part of the query that is used in the Videos Web Part.

+You manage result sources in Central Administration and in site collection administration. If you're familiar with Keyword Query Language (KQL), you can create custom result sources.

+In addition to the predefined result sources, SharePoint Server 2016 automatically creates a result source when you connect a catalog to a publishing site. The automatically created result source is added to the result sources in your publishing site. This result source limits search result to the URL of the catalog, which means that only content from that catalog will be shown when that result source is selected in a Web Part.

+Query rules can be specified for one or more result sources. Result sources are used as part of the query in Web Parts that use search technology, and you can easily influence how search results are shown for all Search Web Parts on your site. By specifying a limited time period for when a query rule is triggered, you can control when certain items are promoted within your website, without having to worry about how to add or remove content at a particular time. Let's say that you're selling electronic products through a product catalog, and you want to promote pink cameras on Valentine's day in the United States. You can create a query rule for a result source that starts on February 14th, and ends on February 15th. The query rule is triggered if a query contains the term Cameras, and pink cameras appear first in the Search Web Part.

+- Recommendations Displayed - number of times a single item, page, or document was displayed as a recommendation.

+- View the usage event data in the **Most Popular Items** usage report. This report applies to all items in a library, and lists the most popular items for each usage eventΓÇöfor example, a list of the most viewed pages in a library.

+- View the usage event data in the **Popularity Trends** report. This report applies to a Site Collection, a Site, or an individual item in a library or list. The report shows the daily and monthly counts for each usage eventΓÇöfor example, the total views of a page on a specific day.

+When you set up a new site, there hasn't been any user traffic to generate usage events. Therefore, there will be no recommendations and popular items in the system. To be able to show recommendations and popular items from the beginning, you can import existing events from a previous SharePoint system, or import events from a third-party web analytics provider. To correctly import existing data, the data have to be formatted according to specific rules.

+Trusted data connection libraries are SharePoint Server 2013 data connection libraries that contain data connection files that Excel Services will trust to use to connect to databases. These files contain everything that Excel Services and Excel client have to connect to an external data source.

+Excel Services doesn't use data connection files that aren't stored in a trusted data connection library. However, data connection information can be embedded directly in a workbook that is trying to make a connection.

+For workbooks that use the same data connection file, changing the data connection file is all that is required to change connection information; changing the individual workbooks isn't necessary.

+- The frequency of data refreshes for data-connected diagrams

+The diagram size limit and refresh parameters can be adjusted by the administrator. Being able to adjust these parameters can help you adjust the performance of the server. If changing these parameters doesn't provide the desired performance, you may have to add processing capacity or memory.

+When planning system resources for Visio Services, the most important factor is peak load. For example, if users will make heaviest use of the Visio Services functionality early Monday morning, plan your server capacity for that peak load. Peak load times can vary widely depending on how Visio Services is used within your organization. It's important to estimate peak loads as best as possible to avoid overtaxing system resources.

+- Monitor the performance of the application servers in the farm and add CPU and memory or additional Front-end role servers if they're needed to handle peak loads.

+To help determine capacity requirements for Visio Services, consider rolling Visio Services out to a limited pilot group that is representative of typical users. Giving a fairly small amount of people access to Visio Services functionality lets you monitor server resource usage and effect on related systems, such as external data sources, without overtaxing system resources.

+We highly recommend that you monitor system resources consumed by Visio ServicesΓÇöalongside the other services in your SharePoint Server farm. It's typical for resource usage to increase over time as additional users are brought online and existing users make more use of Visio Services and other SharePoint Server technologies.

+Visio Services settings and Visio documents stored in SharePoint Server libraries can be backed up by the farm administrator when doing a standard farm backup. However, be aware that when working with Visio documents that are connected to data sources that are outside the farm, the data to which the Visio documents are connected isn't backed up as part of a standard farm backup. In this case, the administrator of the system where the data resides should perform a separate backup procedure.

+Visio Services lets you display Visio diagrams in a Web Part without the need to have Visio installed on the client computer. However, Visio Services doesn't allow for creating or editing Visio diagrams. As part of your deployment plan for Visio Services, you should also plan for the needs of diagram authors within your organization. Each diagram author who has to use Visio Services must have a copy of Visio Professional, Visio Premium, or Visio Pro for Microsoft 365.

+With organizations increasingly using SharePoint for rich contents rather than normal documents, the storage requirements have grown multifold. Administrators must regularly review and clean up contents in the SharePoint. By default, all the structured content such as metadata, or unstructured content such as files, are stored in content databases in the SQL server attached to SharePoint Server. Unstructured data in SharePoint are stored in content database as Binary Large Object (BLOB) and they're immutable.

+- There's a PowerShell Cmdlet to check the data completeness to figure out storage problem.

+Remote Share Provider introduces the new storage system into SharePoint. Any other system can introduce complexity and reliability downgrade in some circumstances. As it's based on RBS, following are some of the limitations that are also applicable to Remote Share Provider:

+- Encryption isn't supported on BLOBs, even if transparent data encryption is enabled.

+- RBS doesn't support using data compression.

+- As content database and BLOB storages are separated, backup and restore from farm, and content database level aren't enough for disaster recovering. BLOB storages need to be backed up and recovered at the same time when performing farm and content database level backup and recovery.

+- Another storage layer reduces availability and reliability of the overall system that is High availability and Disaster Recovery (HADR) won't work by default until you set up HADR for SMB storage.

+- Site collection isn't for time-critical business. If the site collection is down, you can take time to restore content database and remote BLOB storage. Service downtime for this specific site collection won't have significant impact to organization business.

+It's recommended to use System Center Data Protection Manager (DPM) to manage backup and restore so that content database and remote BLOB storage can be backed up at the same time.

+In DPM, you can create protection group for both SharePoint content database and remote SMB storage so that these data sets can be backed up/managed together by DPM. For more information, see:

+If you don't use DPM to manage backup and restore, you can follow the two steps to back up SharePoint in sequence:

+2. Restore content database or farm by using Restore-SPFarm PowerShell cmdlet.

+Remote Share Provider doesn't provide encryption to ensure the data security. It relies on the security and access control provided by SMB storage. Hence, to keep your BLOB data safe from threats, proper actions must be taken at the storage level.

+By moving to new Remote Share Provider, this SQL Server level HADR can't cover the BLOBs inside SMB storage. Hence, Remote Share Provider can't support same as SQL server HADR by default. It requires more cost and effort to set up a HADR-ready SMB storage and integrate with SharePoint and SQL server with layer HADR system.

+ For this configuration, there are two sets of SharePoint servers and SQL servers, however, they share the same SMB storage for BLOBs. Real-time database synchronization is set up to stream changes from active SQL server in active SharePoint farm to failover SQL server in failover SharePoint farm. So if there's any problem in active SharePoint farm, admin can immediately switch to fail over SharePoint farm.

+ This configuration is exactly the same as configuration #1 except there's a failover backup for SMB BLOB storage. Not only database is synced but SMB storage is also backed up. In this situation, when active SharePoint farm has problem, it can switch to fail over farm with other setting to change the SMB storage UNC path to failover SMB storage.

+Remote Share Provider doesn't provide encryption to ensure the data security. It relies on the security and access control provided by SMB storage. Therefore, to keep the BLOB data safe from threats, proper actions must be taken at the storage level:

+- The user account used to perform the steps in the [Provision a BLOB store for each content database](/sharepoint/administration/install-and-configure-rbs#provision) section must be a member of the `db_owner` fixed database role on each database that you're configuring RBS for.

+- The user account installing the client library in the steps in the [Install the RBS client library on SQL Server](/sharepoint/administration/install-and-configure-rbs#library) and each front-end or application server section must be a member of the administrators' group on all of the computers where you're installing the library.

+Ensure that there's a master key for this content database for which you want to apply RBS. If the master key doesn't exist, create a new one for the content database.

+1. Confirm that the user account performing these steps is a member of the `db_owner` fixed database role on each database that you're configuring for RBS.

+6. Paste the following SQL queries in **Query** pane, and then run them in the sequence listed. In each case, replace `[WSS_Content]` with the content database name, and replace `c:\BlobStore` with the `volume\directory` in which you want the BLOB store created. The provisioning process creates a folder in the location that you specify. You can provision a BLOB store only once. If you attempt to provision the same BLOB store multiple times, you'll receive an error.

+To access restricted SMB storage, it's recommended that specific domain account is assigned to Remote Share Provider to READ/WRITE BLOB files in SMB storage. The provider is using PSCredential object to sign-in remote RBS storage with this specific account credential.

+The PSCredential object, which is used to access the SMB storage. If this parameter isn't specified, it will use the service account, which is applied to the current web application.

+The number of BLOB trunks in each BLOB pool. If this parameter isn't specified, it will be set to 1000.

+The registered remote share BLOB store won't take effect until it's activated. `Switch-SPBlobStorage` cmdlet needs to be run after `Register-SPRemoteShareBlobStore`, so that new contents to the content database will be routed to the newly created remote share BLOB store.

+This cmdlet will switch default BLOB storage of the content database to the given remote share BLOB store. Since BLOB store is unique in farm and linked to specific content database, there's no need to specify the content database in this cmdlet.

+One content database can have several BLOB stores, and at any time only one of these BLOB stores can be active for WRITE while others are just for READ. Sometimes, there's a need to move BLOBs from one BLOB store to another. For example, you may need to set up a new SMB storage and move all BLOBs to the new SMB storage. In this situation, you need to migrate data from SQL or old BLOB stores to the new BLOB store.

+This switch forces unregistration even when the RemoteShareBLOBStore isn't active but the BLOBs are still in use. If there's need to unregister such BLOB store, you can run the cmdlet with this switch to ignore the detection of in-use BLOBs in the BLOB store. If the blob store is active in the content database, this cmdlet will throw an exception to prevent unintentional unregistering of a BLOB store in-use.

+We don't recommend using this **-Force** switch because it will leave BLOBs in the SMB storage behind and make your SharePoint contents unaccessible. We recommend migrating BLOBs firstly and then unregister remote share BLOB store.

+- By default, SharePoint won't allow you to remove a certificate if it's currently assigned to a SharePoint object. You must override the default behavior if you want to force the removal of a certificate. If you override the default behavior, existing assignments of the certificate are cleared.

+- The certificate and any private key associated with it's removed from the SharePoint configuration database.

+- Any previous exports from the certificate through the SharePoint administration interface won't be removed. Those exported files will still exist.

+Farm-level recovery is performed only after a failure that involves the complete farm, or where partial recovery of part of the farm isn't possible. If you only have to restore part of the farm, a specific database, a service application, a list, or document library, or a specific document, use another recovery method. For more information about alternate forms of recovery, see [Related content](#proc4).

+ Farm recovery is performed for any of the following reasons:

+- You can't back up from one version of SharePoint Server 2019 and restore to another version of SharePoint Server 2019. The same applies to SharePoint Servers 2016 and 2013.

+- Backing up the farm will back up the configuration and Central Administration content databases, but these can't be restored using SharePoint Server tools. For more information about how to back up and restore all of the farm databases, see [Move all databases in SharePoint Server](move-all-databases.md).

+- When you restore the farm by using SharePoint Server, the restore process won't automatically start all of the service applications. You must manually start them by using Central Administration or Microsoft PowerShell. Don't use SharePoint Products Configuration Wizard to start the services because doing this will also reprovision the services and service proxies. For more information, see [Start or stop a service in SharePoint Server](start-or-stop-a-service.md).

+ When you restore an existing database and don't use the overwrite option, a new ID is assigned to the restored database, and the database change log isn't preserved. The next crawl of the database will add data from the content database to the index.

+ If a restore is performed and the ID in the backup package is already being used in the farm, a new ID is assigned to the restored database and a warning is added to the restore log. The ability to perform an incremental crawl instead of a full crawl depends on the content database ID being the same as before and the change log token that is used by the search system being valid for the current change sign-in the content database. If the change log isn't preserved, the token isn't valid and the search system has to perform a full crawl.

+- SharePoint Server backup backs up the Business Data Connectivity service external content type definitions but doesn't back up the data source itself. To protect the data, you should back up the data source when you back up the Business Data Connectivity service or the farm.

+ If you restore the Business Data Connectivity service or the farm and then restore the data source to a different location, you must change the location information in the external content type definition. If you don't, the Business Data Connectivity service might be unable to locate the data source.

+- SharePoint Server restores remote Binary Large Objects (BLOB) stores only if you're using the FILESTREAM remote BLOB store provider to put data in remote BLOB stores.

+ If you're using another provider, you must manually restore the remote BLOB stores.

+- If you're sharing service applications across farms, be aware that trust certificates that were exchanged aren't included in farm backups. You must back up your certificate store separately or keep the certificates in a separate location. When you restore a farm that shares a service application, you must import and redeploy the certificates, and then re-establish any inter-farm trusts.

+- After a Web application that is configured to use claims-based authentication is restored, duplicate, or additional claims providers are often visible. If duplicates appear, then you must manually save each Web application zone to remove them. For more information, see [Restore web applications in SharePoint Server](restore-a-web-application.md).

+ - Administrators group on the server on which you're running the PowerShell cmdlets.

+ > If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For more information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps&preserve-view=true).

+ If you don't specify the `BackupId`, the most recent backup will be used. To view the backups for the farm, at the Microsoft PowerShell command prompt, type the following command:

+ You can't use a configuration-only backup to restore content databases together with the configuration.

+3. On the Restore from BackupΓÇöStep 1 of 3: Select Backup to Restore page, from the list of backups, select the backup job that contains the farm backup, and then click **Next**. You can view more details about each backup by clicking the (+) next to the backup.

+4. On the Restore from BackupΓÇöStep 2 of 3: Select Component to Restore page, select the check box that is next to the farm, and then click **Next**.

+5. On the Restore from BackupΓÇöStep 3 of 3: Select Restore Options page, in the **Restore Component** section, make sure that **Farm** appears in the **Restore the following component** list.

+Although you can't restore the complete farm by using SQL Server tools, you can restore most of the farm databases. If you restore the databases by using SQL Server tools, you must restore the farm configuration by using Central Administration or PowerShell. For more information about how to restore the farm's configuration settings, see [Restore farm configurations in SharePoint Server](restore-a-farm-configuration.md).

+2. If the SharePoint Timer service is running, stop the service and wait for several minutes for any currently running stored procedures to finish. Don't restart the service until after you restore all the databases that you have to restore.

+ The database is automatically taken offline during the recovery operation and can't be accessed by other processes.

+8. In the **Restore options** section, select only **Overwrite the existing database**. Unless your environment or policies require otherwise, don't select the other options in this section.

+ - The third option, **RECOVER WITH STANDBY** isn't used in this scenario.

+11. Except for the configuration database, repeat steps 4 through 9 for each database that you're restoring.

+- You can only restore one web application at a time by using the procedures in this article. However, at the same time, you can restore all the web applications in the farm by restoring the complete farm.

+- You can't use SQL Server tools to restore a web application.

+ - Administrators group on the server on which you're running the PowerShell cmdlets.

+ > If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For more information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps&preserve-view=true).

+ If you don't specify the value of the `BackupID` parameter, the most recent backup will be used. You can't restore a web application by using a configuration-only backup. You can view the backups for the farm by typing the following:

+You can't restore the complete web application by using SQL Server tools. However, you can restore all the databases that are associated with the web application. To restore the complete web application, use either PowerShell or Central Administration.

+2. If the SharePoint Timer service is running, stop the service and wait for several minutes for any currently running stored procedures to finish. Don't restart the service until after you restore the databases.

+ The database is automatically taken offline during the recovery operation and can't be accessed by other processes.

+8. In the **Restore options** section, select only **Overwrite the existing database**. Unless the environment or policies require otherwise, don't select the other options in this section.

+11. Repeat steps 4 through 10 for each database that you're restoring.

+After a web application that is configured to use claims-based authentication is restored, duplicate, or additional claims providers are often visible. You must use the following process to remove the duplicate providers:

+## Additional steps to reconfigure object cache user accounts in SharePoint Server

+If you configured object cache user accounts for the web application, the restore process won't restore these settings. You must reconfigure the settings for the web application. For more information, see [Configure object cache user accounts in SharePoint Server](configure-object-cache-user-accounts.md).

+If you're a website owner, you know how important it's that users can easily find your website by using Internet search engines such as Bing or Google. The higher your website is shown in the search results list, the more likely it's that users will click on it. Just think of your own behavior when looking at search results. When was the last time that you clicked to view the second page of search results?

+After completing these stages, our Contoso site is starting to look good, but now it's time to make sure that our site visitors can find the exact product they're looking for, quickly and easily. This article focuses on what we must plan before we begin to configure refiners.

+Although the term "refiners" might sound new to you, there's a high chance you've already used them, and much more often than you think. For example, if you've ever bought a book online, most likely refiners were there to help locate just the right book.

+Let's consider a hypothetical situation in which you're planning a trip to Japan. You visit your favorite online bookstore in search of a travel guide for your trip. You type "Japan" and, pages of search results are returned. Trawling through page after page of search results doesn't seem like much fun. Luckily, the site designers have provided a way to narrow the search results. On the left side of the page is a "Categories" list, which contains entries such as "Cooking," "Geography," "History," and "Travel." You click "Travel" and in an instant, the search results show only travel books that contain the word "Japan." But, turns out there are many travel books out there on Japan. Therefore, you have to trim the results additionally. As it happens, you want a paperback version. So, still focusing on the lists on the left side of the page, you spot a category called "Format" that contains terms like "Hardcover," "PDF," "Audio," Digital," and "Paperback." So you click "Paperback" and received what you've been after: results for travel books about Japan in paperback! Unfortunately, the number of search results is still too large. Therefore, you continue to use the category lists on the left side of the page until you've drilled right down to five hopeful candidates, one of which makes it over the finish line and straight into your shopping cart.

+Earlier in this series, the article [From site column to managed property - What's up with that?](from-site-column-to-managed-propertywhat-s-up-with-that.md) explained how a site column is represented as a managed property after they were crawled. For example, in our Contoso catalog we have a site column named "Contoso Color." For each item in the catalog, we have added a color value, such as red, green, or blue, to this column. To enable our site visitors to narrow search results quickly (for example, to a particular color), we must enable the managed property that represents the "Contoso Color" site column as a refiner. There is, of course, more to it than that, and we'll show you all these steps in later articles.

+Now, you might be thinking that stand-alone refiners seem like an excellent refiner type to use on a search results page. But what about a scenario like our Contoso site, where we show catalog content? On our Contoso site, visitors want to browse the catalog to find what they're looking for. Therefore, they won't enter any words into a search box. Well, remember that we're using a Content Search Web Part to display content on our search page, as explained in [Stage 9: Configure the query in a Content Search Web Part on a category page in SharePoint Server](stage-9-configure-the-query-in-a-content-search-web-part-on-a-category-page.md). Because the Content Search Web Part is using search technology to display search results, we can use refiners to narrow search results that are displayed in the Content Search Web Part.

+So we can use refiners on our category page. That's nice, but again you might be thinking: What if we want to use different refiners for different categories? For example, on the "Televisions" category, we want visitors to be able to refine on "Screen Size." On the "Air conditioners" category it doesn't make sense to have a refiner called "Screen Size," so we don't want to display it there. But, we do want visitors to be able to refine on "Installation type." In addition, there are some common refiners that should be applied to all categories, such as "Brand."

+By default, all children of a term inherit refiners that are added to a parent term. For example, a refiner that is added to the term "Cameras" will be applied to all its children, such as "Camcorders," "Camera accessories," and so on, You can override this inheritance to add or remove refiners for a child category. Later in this series, we'll look at how this is done. For now, let's concentrate on the planning part.

+Basically, there are two ways refiner values can be displayed: as a list, or grouped in intervals. For refiner values that use the data type Text, Person or Group, Choice or Yes/No, there's not much to consider. These refiner values will most likely always be displayed in a list as shown in the screenshot below.

+But, for numeric refiner values, the story is different. For example, consider all the refiner values for a refiner such as Price. In our Contoso scenario, it could overwhelm our visitors with information and would therefore not be of much us.

+[Stage 15: Add refiners for faceted navigation to a publishing site in SharePoint Server](stage-15-add-refiners-for-faceted-navigation-to-a-publishing-site.md) explained how to add refiners for faceted navigation to a publishing site. By using category-specific refiners, visitors can easily find the product they're looking for. But, visitors can't easily see the different subcategories inside a particular category.

+Throughout this series, when a new feature was introduced, we started by explaining the feature, and then went on to the procedures for using it. In this stage, we'll flip the sequence, because it will be easier to explain what's going on by using screenshots of the Web Part.

+That's all there's to it! Without having to do any configuration, the subcategories under "Cameras" are displayed. Also notice that refiner counts are automatically displayed.

+Now let's look at how these subcategories "magically" appear.

+Let's start with a definition of this Web Part: The Taxonomy Refinement Panel Web Part filters search results from an associated Search Web Part, which show refiners based on the current navigation term. For example, in our case, the Web Part showed the subcategories of "Audio" and subcategories of "Computer".

+1. The Taxonomy Refinement Web Part must be associated with another Search Web Part on the page that it's added to.

+In the following screenshot, the Taxonomy Refinement Panel Web Part is shown in the default edit mode. In the Web Part Tool Pane, in the **Query** section, **Refinement Target** is set to **Content Search - Default**.

+To visitors, this makes browsing for products convenient, because they can immediately see which subcategories have *Fabrikam* camera products, without having to click back and forth.

+So, that was all for this series. If you're setting up your own site, we hope you'll make good use of the features that are described in this series.

+After we've set up our Product Catalog Site Collection, as described in [Stage 1: Create site collections for cross-site publishing in SharePoint Server](stage-1-create-site-collections-for-cross-site-publishing.md), we can import content into this site collection. To do this, use PowerShell scripts. But before we start, let's take a look at what is automatically created in a **Product Catalog Site Collection**.

+To import list content into the **Products** list, use PowerShell scripts that will:

+Before we can run the PowerShell scripts, we have to prepare the following:

+- List content in the **Products** list. In our scenario, each list item is a product that Contoso wants to display on their website.

+- In the **Products** list, content in the **Item Category** column is associated with the correct term from the **Product Hierarchy** term set. The following screenshot shows how the list item *Southridge Video Laptop15.4W M1548* is associated with the term *Laptops* through the **Item Category** column.

+[Configure cross-site publishing in SharePoint Server.](configure-cross-site-publishing.md)

+As described in [Stage 2: Import list content into the Product Catalog Site Collection in SharePoint Server](stage-2-import-list-content-into-the-product-catalog-site-collection.md), we've imported content about Contoso's product line into the **Products** list. To display this product information in our Publishing Portal (the Contoso website), we must enable the **Products** list as a catalog.

+By doing this, we grant anonymous visitors, that is, visitors who aren't logged on to Contoso's website, access to view content from this list.

+We're **not** granting visitors access to the list itself. All we're doing is granting anonymous visitors access to **view** the catalog content from the search index. Anonymous visitors will never be able to see the actual **Products** list.

+The URL to a specific product will be composed of the terms that we specify in **Navigation Hierarchy** (previous step), *and* the values from the fields we specify as **Catalog Item URL Fields**. When selecting these fields, we should use at least one field that contains a product unique value, because we want to use this unique value in the product URL. By doing this, the URL to the product *Fabricam Home Movimaker M300* will differ from the URL to the product *Fabricam Home Movimaker M400*.

+The CSWP contains a default query. Therefore, it already displays some content (Audio, Cameras, and Computers). But it doesn't display the content we want to display. To make the Web Part display Contoso catalog content, we must configure the query in the Web Part.

+Our query in the CSWP will therefore display search results for items that are in the *catalog - Products Results result source, and are tagged with either "Audio", or any child of "Audio", for example "MP3 players" or "Speakers".

+Another key phrase from the selection **Restrict by current and child navigation** terms is *current* . More information about the importance of this phrase is provided in [About the query configuration](stage-9-configure-the-query-in-a-content-search-web-part-on-a-category-page.md#BKMK_AboutTheQueryConfiguration) in the next section.

+If you're now thinking "OK, I understand how we got the correct search results for the "Audio" category, because that is the category we clicked, and where we changed the query in the Web Part. But why do we see different search results when we browse the catalog? And shouldn't we change the query for all the other categories also?"

+We only had to configure the query one time, because the query issued from the Web Part differs depending on which category we browse to. Remember that the CSWP contains a query that is automatically issued when someone browses to a page that contains a CSWP, and that search results are displayed in the Web Part. Also, remember that we selected **Restrict by current and child navigation terms** when we configured the query in the Web Part. The word "current" is important here, because it means that the query issued by the CSWP will change depending on the category the visitor is currently browsing. If you edit the Web Part from another category, you can see that the Web Part has changed.

+To view details of the query configuration, click on the **TEST** tab. The actual query issued by the CSWP is shown in the **Query text** field.

+If this doesn't make any sense now, don't worry! There's logic to it, and we'll break it down to make it clearer.

+The next step is to add a CSWP to our catalog item page.

+The following issues can help reduce the effect of performance issues that are related to the extensive use of fine-grained permissions. Each of the following issues covers changes to the environment security, object hierarchy or custom code that is contributing to the performance issues that are related to fine-grained permissions. Each issue starts with the following example environment where a single web contains multiple document libraries, each with many uniquely permissioned child objects.

+To rearchitect the environment so that it no longer requires fine-grained permissions, an environment cleanup process can be implemented, and then the number of scoped items can be adjusted to improve the scalability of the environment over the longer term. The following recommendations describe the environment cleanup and architectural security changes that are required to achieve this solution.

+After the existing fine-grained permissions and scopes are removed, the long-term architecture plan should be to maintain a unique scope only at the web level. The following diagram shows how this might be structured so that only the web-level scope remains. The core requirement in the architecture isn't to have too many items at the same level of hierarchy in the document libraries, because the time that is required to process items in the views increases.

+If more changes are needed to the architecture, consider moving document libraries to different webs or site collections. The number of document libraries could also be changed to more closely support business needs and scaling recommendations that are based on the taxonomy or audience of the stored content.

+To rearchitect the environment so that it still uses fine-grained permissions, but without causing too many updates to or sizing of a single web scope, consider moving differently secured document libraries to different webs.

+In the following diagram, the physical architecture was changed so that each document library is in a uniquely permissioned web. Additionally, when item-level fine-grained permissions must be preserved, as a best practice the cumulative number of security principals who will be granted access should be limited to approximately 2,000, although this isn't a fixed limit. Therefore, the effective membership of each web that includes all Limited Access members users, should be no more than approximately 2,000 users. This keeps each web-level scope from growing too large.

+The number of uniquely scoped children isn't a significant issue, and can scale to large numbers. However, the number of principles that will be added as limited access up the chain of scopes to the first uniquely permissioned web will be a limiting factor.

+To rearchitect the environment so that it still uses fine-grained permissions, but without causing too many updates to or sizing of a single web scope, consider using a different process of securing items. This is applicable if the cause of the large number of unique scopes was an automated process such as an event handler or workflow that dynamically changed object permissions. The recommendation in this case is to make a code change to whatever process was creating the unique security scopes.

+In the following diagram, the scope architecture was changed so that scope membership doesn't cause ACL recalculation at the parent document library and web. As mentioned earlier, the effective membership of the web that includes all Limited Access members, should be no more than approximately 2,000 to keep the web-level scope from growing too large. In this case, by implementing a new SharePoint group to hold all members who should have Limited Access rights, the scope won't grow too large. When users are added to individual scopes under the web level by using the SharePoint Server **SPRoleAssignmentCollection.AddToCurrentScopeOnly** method, they can also be added, by extra code, to the new group that was established as having Limited Access rights at the web and document library level.

+When item-level fine-grained permissions must be preserved, the cumulative number of security principals who will be granted access should be limited to about 2,000, although this isn't a fixed limit. When the number of security principals increases, it takes longer to recalculate the binary ACL. If the membership of a scope is changed, the binary ACL must be recalculated. The addition of users at a child item unique scope will cause parent scopes to be updated with the new Limited Access members, even if this ultimately results in no change to the parent scope membership. When this occurs, the binary ACL for the parent scopes must also be recalculated.

+As in the previous solution, the number of uniquely scoped children isn't a significant issue, and can scale to large numbers. The number of principles that will be added as limited access up the chain of scopes to the first uniquely permissioned web will be a limiting factor.

+Unlike typical IIS applications, you can't use IIS Manager or other IIS metabase tools to modify the bindings of IIS web applications that have been extended with SharePoint Server.

+If you modify the IIS bindings of a web application by adding a host header binding or SSL port or by changing a port number, SharePoint Server won't be aware of these changes and won't update the web application's alternate access mapping URLs. If you update the web application's alternate access mappings to change a host header, switch to an SSL URL, or change a port number, SharePoint Server won't automatically update your IIS bindings to match.

+We don't recommend reusing the same IIS website for your HTTP and SSL hosting. Instead, extend a dedicated HTTP and a dedicated SSL website, with each assigned to its own alternate access mapping zone and URLs.

+5. In the **Load Balanced URL** section, in the **URL** field, type the URL that users will use to locate this web application. If you're using a load balancer or reverse proxy, this is the URL of the load balancer or reverse proxy.

+If you're using a load balancer or a reverse proxy, make sure that your internal URLs are updated in the alternate access mappings to reflect the new IIS bindings. In addition, update your load balancer rules or your reverse proxy rules to align with the new IIS bindings.

+When you remove SharePoint Server from an IIS website, if you're removing the last (or only) website that is associated with the web application, any web application solutions you have deployed will also be removed. If you need these solutions, redeploy them. For more information about how to manage solutions, see [Install and manage solutions for SharePoint Server](./configure-excel-services.md)

+The following prerequisites must be done installed this upgrade:

+1. In the SharePoint 2013 farm, on the Central Administration website click **Application Management** and click **Manage Service Applications**, and then delete **Workflow Service Application Proxy**.

+### Issue 3: Workflows fail and return the "Can't get app principal permission information" error

+In this scenario, workflows that are created after you connect to the Workflow Manager installation finish successfully. However, workflows that are created before you connect to Workflow Manager don't finish. Instead, they get stuck when they try to finish or they remain in a suspended state. For workflows that remain suspended, you receive an HTTP 500 error. Additionally, the following entry is logged in the ULS log: *Can't get app principal permission information.*

+11/03/2017 12:13:16.72 w3wp.exe (SPWFE01:0x51FC) 0x1298 SharePoint Foundation Authentication Authorization an3eg Medium Can't get app principal permission information. AppId=i:0i.t|ms.sp.ext|\<SPWeb object ID\>@\<SPAuthenticationRealm\>

+11/03/2017 12:13:16.72 w3wp.exe (SPWFE01:0x51FC) 0x1298 SharePoint Foundation General 8nca Medium Application error when access /site/teamsite/teamweb/_vti_bin/client.svc, Error=Object reference not set to an instance of an object at Microsoft.SharePoint.SPAppRequestContext.EnsureTenantPermissions(SPServiceContext serviceContext, Boolean throwIfAppNotExits, Boolean allowFullReset) at Microsoft.SharePoint.SPAppRequestContext.InitCurrent(HttpContext context) at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.InitCurrentAppPrincipalToken(HttpContext context) at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.PostAuthenticateRequestHandler(Object oSender, EventArgs ea) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

+- BandwidthΓÇöThe data transfer capacity, or speed of transmission, of a digital communications system as measured in bits-per-second (bps).

+- LatencyΓÇöThe time that is required for a request to travel from one point on a network to another point.

+A Microsoft 365 environment demands higher levels of performance over WAN connections because many customers are geographically distributed. As a result, Microsoft 365 was extensively tested under WAN conditions. Testing scenarios included latencies up to 300 milliseconds, which is higher than latencies between the North America and Asia.

+- Servers respond to http and https requests faster.

+- Active download management and script on demandΓÇöthese optimizations prioritize resources and JavaScript to download the content that is most meaningful to users first.

+- Minimal download strategyΓÇöAs users browse SharePoint content, only changes to a page are downloaded and sent to the client.

+The following diagrams detail the effect of WAN performance optimizations on one of the most popular pages in SharePointΓÇöTeamsite. The diagrams show network traces of Teamsite for both SharePoint 2010 and SharePoint Server 2013 with the following network conditions:

+These conditions represent higher latencies and lower bandwidths than are typical for global WAN connections. However, some customers who have remote sites find themselves within this range (for example, mining, oil and gas, and global construction companies). 1 mpbs bandwidth connection is lower than a typical mobile phone connection.

+In the two network traces, the horizontal rows represent the ports that are open. The colored blocks represent content that is traveling over the wire, such as the images, JavaScript, and HTML. In the SharePoint 2010 network trace, the white spaces between the colored blocks represent idle time in which the client or server is waiting for something to happen before completing the next action. In the SharePoint Server 2013 network trace, the network pipe is filled almost 100%. Communication between the client and server is ongoing until the transaction is complete. There's little or no idle time between actions. These improvements are provided by the optimizations described earlier in this article (minimal download strategy, active download management, and script on demand).

+This following diagram of the network traces shows that the content that users interact with on the page (the document library, prompts, navigational elements, etc.) are downloaded a full second faster in SharePoint Server 2013 compared to SharePoint 2010. Users can interact with the site sooner.

+- Downloads 20% more bytes for the JavaScript, which provides quicker and improved functionality in the browser.

+**Teck unit testΓÇöFile upload from Santiago to Calgary (140ms latency) with Riverbed device**

+To repeat this unit test, the Microsoft SharePoint writing team had colleagues in the Beijing office connect to SharePoint sites in the Redmond office. In this scenario, two writers repeated the test multiple times throughout the day and produced a range of results. Files with different content were used each time to avoid potential caching issues, although a WAN accelerator device isn't used between the two locations. The following table records the results.

+**Microsoft writing team unit testΓÇöFile upload from Beijing to Redmond (144ms latency)**

+Here are recommendations if you conduct your own unit testing:

+Before you begin any type of systematic load testing across a WAN environment make, sure that you understand the nature of your network. You should have data about bandwidth, latency, network congestion, packet loss and types of devices between users and the SharePoint front-end web server. This data isn't always easy to obtain. However tools, such as System Center Operations Manager, can make it easier.

+After you address WAN constraints, you can start to use a combination of tools to testing WAN efficiency. Prescriptive tools, such as Visual Studio 2012 Update 1, provide repeatable unit and load testing capabilities. Nonprescriptive tools, such as Microsoft Network Monitor (Netmon) with Visual Round Trip Analyzer, provide end-user oriented monitoring. Both types of tools can be useful because they each provide a different approach to WAN testing and data collection. The combined results can provide a complete view of the impact of WAN connections on user performance.

+The goal is to have a well-rounded set of unit tests, which capture actions that end-users perform in a SharePoint environment and expose any potential latency-sensitive transactions.

+Finally, make sure that you conduct rounds of tests at various times throughout the day to capture differences in network utilization patterns. For example, 09:00 on Monday morning may have a different network and performance pattern compared to 23:00 on Friday. Also, be aware of events in other geographical regions, such as a natural disaster that results in region-wide power outages, that might impact WAN routing or performance. A comprehensive set of tests spread across different time intervals will provide insight and set expectations about what your end-users will experience when they use SharePoint Server 2013 across the WAN.

+**FabrikamΓÇöResults across the feature set for different locations**

+Fabrikam is an example of a world-wide company that succeeds with a central datacenter model, instead of deploying SharePoint Server 2013 to multiple regions across the world. If your plans include a move from a central datacenter model to multiple SharePoint sites in different geographical regions, make sure that you conduct WAN testing to see whether it's necessary.

+Document Sets are a feature in SharePoint Server that enables an organization to manage a single deliverable, or work product, which can include multiple documents or files. A Document Set is a special kind of folder that combines unique Document Set attributes, the attributes, and behavior of folders and documents, and provides a user interface (UI), metadata, and object model elements to help manage all aspects of the work product.

+In SharePoint Server, organizations that want to create and manage Document Sets consistently can configure a Document Set content type for each work product they typically create. A Document Set content type can then define approved content types, attributes, default items, columns, workflows, and policies. More customized Document Set content types can then be created from the parent content type, each inheriting properties and settings from the parent Document Set content type. After the content type is added to a library, users can then create a Document Set that inherits the attributes of the Document Set content type by using the **New** command. A Document Set content type provides additional settings that enable you to specify allowed content types, default content, shared columns, Welcome Page columns, and default Welcome Page view.

+- There's no limit on the number of documents that can exist in a Document Set. However, display load times may be limited by the list view threshold, which by default is set at 5,000 items. Folders are allowed in document sets, but metadata navigation can't be used in a Document Set. Therefore, it's important to consider the possibility of exceeding list view thresholds and navigation design concerns when you determine how many items should exist in a Document Set. In addition, when you use the **Send to** feature with a Document Set, the sum for all documents in a Document Set can't be larger than 50 MB. For a collection or work product with a large number of items, a folder structure in a document library may be a better solution.

+- There's no limit on the number of Document Sets that can exist in a document library. However, the number of Document Sets that can appear in lists will be limited by the list view threshold.

+- When using shared metadata, if there are more than 10 items that are using shared metadata in a Document Set, metadata updates will be run by a timer job every 15 minutes. For example, if you have 10 documents in the top level of the library, and a single document in a Document Set with shared metadata, the time job won't run. But if you add another Document Set with nine more documents, the timer job will run.

+- Determines how active documents that will become records should be handled while they're being used, and determines how they should be collected after they're declared to be records.

+- Researches and implements technological solutions and business processes to help ensure that the organization complies with its records management obligations in a cost-effective and nonintrusive way.

+Determining which documents and other physical or electronic items in your organization are records is the responsibility of corporate compliance officers, records managers, and lawyers. By carefully categorizing all enterprise content in your organization, these people can help you ensure that documents are retained for the appropriate period of time. A well-designed records management system helps protect an organization legally, helps the organization demonstrate compliance with regulatory obligations, and increases organizational efficiency by promoting the disposition of out-of-date items that aren't records.

+- **A content analysis** that describes and categorizes content in the enterprise that can become records that provides source locations and that describes how the content will move to the records management application.

+- **A method for auditing records** while they're active.

+This article describes the planning steps that you should take to help make sure that the records management system that you implement based on SharePoint Server will achieve your organization's records management goals. The following is a preview of the records management planning process:

+ - Content managers to find where organizational information is kept and to make sure that their teams follow records management practices.

+3. **Develop a file plan** After you have analyzed your organizational content and determined retention schedules, fill in the rest of the file plan. File plans differ from organization to organization, but generally they describe the kinds of items the enterprise acknowledges to be records, indicate where they're stored, describe their retention periods, and provide other information, such as who is responsible for managing them and which broader category of records they belong to.

+4. **Develop retention schedules** For each record type, determine when it's no longer active (being used), how long it should be retained after that, and how it should ultimately be disposed of.

+6. **Design the records management solution** Determine whether to create a records archive, to manage records in place, or to use a combination of the two approaches. Based on your file plan, design the record archive, or determine how to use existing sites to contain records. Define content types, libraries, policies, and, when it's required, metadata that determines the location to route a document to.

+7. **Plan how content becomes records** If you're using SharePoint Server for both active document management and records management, you can create custom workflows to move documents to a records archive. If you're using either SharePoint Server or an external document management system, you can plan and develop interfaces that move content from those systems to the records archive, or that declare a document to be a record but don't move the document. You also create a training plan to teach users how to create and work with records.

+8. **Plan email integration** Determine whether you'll manage email records within SharePoint Server, or whether you'll manage email records within the email application itself.

+description: "Workflows in SharePoint allow you to model and automate business processes. These business processes can range from simple to complex. But most importantly, workflow lets users focus on doing the work--rather than managing the workflow."

+Workflows in SharePoint allow you to model and automate business processes. These business processes can range from simple to complex. But most importantly, workflow lets users focus on doing the work--rather than managing the workflow.

+

+SharePoint Server 2019 supports various workflow technologies to meet the needs of our customers. These workflow technologies are described below.

+* The SharePoint 2013 Workflow platform is the recommended workflow technology for SharePoint Server 2019. These workflows integrate with Microsoft Workflow Manager and will provide a stable and reliable workflow experience for SharePoint Server 2019.

+* Power Automate is the new cloud-based platform to automate actions across various applications and services. Thanks to hybrid technology, you can also integrate Power Automate into your SharePoint Server environments using the On-Premises Data Gateway. Each related user must be assigned a Power Apps Plan 1 license to use Power Automate with SharePoint Server, which isn't included as part of the SharePoint Server license. In addition, Power Automate is currently optimized for non-interactive workflows with SharePoint Server. If you require interactive workflows, we recommend exploring the SharePoint 2013 Workflow platform instead.

+* The SharePoint 2010 Workflow platform is also supported in SharePoint Server 2019 for backward compatibility. This allows SharePoint Server 2019 to run legacy workflows from previous versions of SharePoint Server. Although SharePoint 2010 workflows are still supported, we don't recommend building new workflows using this technology. Instead, we recommend exploring either SharePoint 2013 workflows or Power Automate.

+- When a user follows a site in SharePoint Server, it's added to the followed list in both SharePoint Server and Microsoft 365.

+Existing followed sites lists in SharePoint Server aren't migrated to Microsoft 365 when you turn on this feature (though any sites in the Microsoft 365 list will remain there). Users will have to follow their SharePoint Server sites again once the feature is turned on.

+description: "Learn the best practices for SharePoint Server installation and how it gets your servers ready for easy transition to the cloud."

+As you install a new version of SharePoint Server, take time to evaluate any service applications or features that you currently rely on that are no longer supported or listed as "deprecated."

+If you have a reliance on any of the following, plan what you intend to replace that functionality with or if it's no longer being used actively by your company and it's time to phase it out.

+Use supported service applications and consider phasing out the use of these deprecated service applications. For any of the SharePoint BI tools, you can use Power BI as a replacement:

+If you already have a portion of your company in the cloud or plan to do so in the future, know that certain customizations won't transfer to SharePoint. Here's a list of few of those:

+- Workflows, User Alerts, and custom master pages won't transfer to SharePoint. We recommend you use Power Automate for workflows, reconfigure alerts once migrated, and use the out of the box customization for site look and feel changes.

+- Custom Search schema won't transfer to SharePoint. When content is migrated to SharePoint, you may want to reimplement any custom Search schema configuration necessary.

+- Use SharePoint Add-ins with the Low Trust model. To learn more, see [Creating SharePoint add in that use low trust authorization](/sharepoint/dev/sp-add-ins/creating-sharepoint-add-ins-that-use-low-trust-authorization).

+- Use SharePoint Framework solutions for custom business solutions. To get started, see [SharePoint Framework Overview](/sharepoint/dev/spfx/sharepoint-framework-overview).

+Do you use Business Data Connectivity Services (BCS) for any of your data connections? Are your data sources available by using a web service? Verify all data sources are available via other means, such as a web service.

+Instead of using BCS to display your data, you could use Power BI and a Data Management Gateway.

+If a portion of your sites is already in the cloud, or if you intend on moving online in the future, adopting the modern features now will help "futureproof" your installation.

+- Implement only the necessary Web Application Policies, such as self-service site creation, Object Cache, and Search Crawler accounts, but try to avoid further usage of Web Application Policies as they aren't available in SharePoint.

+- For security purposes, phase out the use of anonymous SharePoint Server sites. Also note that anonymous site access isn't available in SharePoint in Microsoft 365.

+If users are accessing Project Server 2016 in the SharePoint farm and have to view their project data in another language, they'll also have to install a corresponding Project Server 2016 language pack. For more information about Project Server 2016 language packs, see [Deploy language packs in Project Server 2013.](/project/deploy-language-packs-in-project-server-2013)

+The language packs that are installed on the web and application servers determine the list of available languages that you can use to create a site or site collection. By default, sites and site collections are created in the language in which SharePoint 2013 was installed. For example, if you install the Spanish version of SharePoint 2013, the default language for sites, site collections, and web pages is Spanish. If someone has to create sites, site collections, or web pages in a language other than the default SharePoint 2013 language, you must install the language pack for that language on the web and application servers. For example, if you're running the French version of SharePoint 2013, and a site owner wants to create sites in French, English, and Spanish, you must install the English and Spanish language packs on the web and application servers.

+Language packs aren't bundled into multilingual installation packages. You must install a specific language pack for each language that you want to support. Also, language packs must be installed on each web and application server to make sure that each web and application server can display content in the specified language.

+Although a site owner specifies a language ID for a site, some user interface elements such as error messages, notifications, and dialogues don't display in the language that was specified. This is because SharePoint 2013 relies on several supporting technologiesΓÇöfor example, the Microsoft .NET Framework, Microsoft Windows Workflow Foundation, Microsoft ASP.NET, and SQL ServerΓÇösome of which are localized into only a limited number of languages. If a user interface element is generated by any of the supporting technologies that aren't localized into the language that the site owner specified for the site, the user interface element appears in English. For example, if a site owner creates a site in Hebrew, and the .NET Framework component displays a notification message, the notification message won't display in Hebrew because the .NET Framework isn't localized into Hebrew. This situation can occur when sites are created in any language except the following: Chinese, French, German, Italian, Japanese, Korean, and Spanish.

+Each language pack that you install creates a folder at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LAYOUTS\Locale_ID that contains language-specific data. In each locale_ID folder, you must have only one HTML error file that contains the error information that is used when a file can't be found. Anytime a file can't be found for any site in that language, this file will be used. You can specify the file to use by setting the **FileNotFoundPage()** for each web application.

+In some cases, some text might originate from the original installation language, which can create a mixed-language experience. This kind of mixed-language experience is typically seen only by content creators or site owners and isn't seen by site users.

+Follow these steps for each language that you want to support. If you decide to download more than one language, please be aware that a unique file that has a common name is downloaded for each language. Therefore, make sure that you download each language pack to a separate folder on the hard disk so that you don't overwrite a language pack of a different language.

+After you install the necessary language files on the web and application servers, you can install the language packs. Language packs are available as individual downloads (one download for each supported language). If you have a server farm environment and you're installing language packs to support multiple languages, you must install the language packs on each web and application server.

+5. Rerun the SharePoint Products Configuration Wizard by using the default settings. If you don't run the SharePoint Products Configuration Wizard after you install a language pack, the language pack won't be installed correctly.

+ The SharePoint Products Configuration Wizard runs in the language of the base installation of SharePoint 2013, not in the language of the language pack that you installed.

+6. If the **Modify SharePoint Central Administration Web Administration Settings** page appears, don't change any of the default settings, and then click **Next**.

+When you install language packs, the language-specific site templates are installed in the %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\TEMPLATE\ _LanguageID_ directory, where _LanguageID_ is the Language ID number for the language that you're installing. For example, the United States English language pack installs to the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\TEMPLATE\1033 directory. After you install a language pack, site owners and site collection administrators can create sites and site collections based on the language-specific site templates by specifying a language when they're creating a new SharePoint site or site collection.

+If you no longer have to support a language for which you have installed a language pack, you can remove the language pack by using the Control Panel. Removing a language pack removes the language-specific site templates from the computer. All sites that were created that have those language-specific site templates will no longer work (It could cause many issues that are, the URL will produce an HTTP 500 - Internal server error page, broken layout, mixture of default, and uninstalled language.). Reinstalling the language pack makes the site functional again.

+You can't remove the language pack for the version of SharePoint 2013 that you have installed on the server. For example, if you're running the Japanese version of SharePoint 2013, you can't uninstall the Japanese language support for SharePoint 2013.

+When it comes to displaying search results, design and content are indeed important. However, there's one thing that often trumps them both: the order in which search results are displayed.

+So, when displaying search results, it's important that the results that your users are looking for are displayed as high up in the search results list as possible. This article, an addendum to the [How to change the way search results are displayed in SharePoint Server](how-to-change-the-way-search-results-are-displayed.md) series, explains how to use a query rule to change the order in which classic search results are displayed. To demonstrate how query rules work, we'll use an example from an internal Microsoft Search Center.

+The following screenshot shows the default order in which search results were displayed in our Search Center. Notice that search results for articles and images were displayed in a mixed order.

+When users search for something in this Search Center, they're usually looking for information about an article. So, to make it easier for users to find information about articles, we wanted to change the order of the search results so that images would be displayed at the bottom. To do this, we had to create a query rule.

+ *"when X (condition), do Y (action)."*

+In our Search Center scenario, we knew the action part: *Display list items that represent images at the bottom of the search results list*.

+In our lists, we use the site column *Content Type* to differentiate between the type of articles or media types a list item represents. For example, all images have the value "Art" for *Content Type*.

+ *When list items are of Content Type "Art," display these at the end of the search results list.*

+ In our Search Center scenario, we named the query rule *Demote Art*.

+6. In the Actions section, specify what you want the query rule to do when it's triggered.

+ Remember, we wanted list items of Content Type *Art* to be displayed at the end of the search results list. So, in the **Manual condition** field, we entered *ContentType: Art*, and selected **Demote to bottom**.

+ - The colon: means "contains".

+ Put it together, and it matches the definition we specified: *When list items are of Content Type "Art," display these at the end of the search results list*.

+In our Search Center scenario, we could easily verify that the query rule we created was being applied. But, if you're uncertain about whether your query rule is being applied, the **Search Results Web Part** can give you an answer.

+2. In the **Query text** section, XRANK was applied to *ContentType: Art*.

+Even though this was a fairly simple query rule, we saw that the effect was noticeable. So a word of warning: even though query rules are great for changing the order in which classic search results are displayed, you should think carefully before you apply too many of them. The effects can be large, and the more complex query rules that you have, the more performance resources each query will require.

+But, if they're used with caution, you can make the users of your Search Center happy customers.

+In [How to display values from custom managed properties in search results - option 1 in SharePoint Server](display-values-custom-managed-properties.md) we showed a simple method to add a custom icon and values from two custom-managed properties to your classic search results. In this article, we'll look at a fuller method for changing the way classic search results are displayed that includes if statements and hit highlighting. In this article, you'll learn:

+Before we look at details about how to achieve these goals, let's look at the strategy we want to follow. If this gets a bit complex, please try to hang in there. Hopefully it will be clear by the end.

+- In the item display template, create a variable that will be used by the property *HitHighlightedSummary* to display our two custom-managed properties with hit highlighting.

+5. Select **Apply** to save the changes. The **Display Templates** section closes.

+10. Because you have no guarantee that the values of your custom properties will contain any of the entered query words, that is, hit highlighting won't be used, you have to create variables that guarantee that the value of your custom properties will be displayed regardless of hit highlighting.

+ The following screenshots show how we created two such variables for our custom properties *ContentSummaryOWSMTXT* and *owstaxIdTechnicalSubject*.

+- The value of *owstaxIdTechnicalSubject* (The query words didn't match the property value, but because of the variable that we created in step 10, the value appears.)

+We wanted to make one little change to how the value for *owstaxIdTechnicalSubject* appears. We wanted to give users a bit more context as to what this value represents. Therefore, we decided to add the text "Technical Subject:" before the value. Also, because this value isn't always present for all list items, we decided it should only display when a value was present.

+In [How to create a new result type in SharePoint Server](how-to-create-a-new-result-type.md), we had decided we wanted six different result types. After creating the *TechNet content* result type and display template, it was easy to copy this work over to the other five result types.

+To make life as easy as possible, when you're adding custom properties to your hover panel, you should leave these three common hover panel display templates as they are, and instead concentrate on the result type specific hover panel display template (highlighted in the illustration below). That's what we did in our Search Center scenario, and it's what we'll demonstrate in this article.

+This may seem confusing now, but we'll show you all the steps that are required in the next two sections. So let's get started!

+Remember when we created the custom item display template *TechNet content, we started by copying the item display template named *Item_Default* (see [How to create a new result type in SharePoint Server](how-to-create-a-new-result-type.md) for more information). The *Item_Default* display template contains a reference to *the Item_Default_HoverPanel* hover panel display template. Because we copied the *Item_Default* display template, our *TechNet content* display template also contains a reference to the *Item_Default_HoverPanel.

+We wanted to use the *Item_Default_HoverPanel* hover panel display template as a basis when we added custom properties to our hover panel. Therefore, in our mapped network drive, we copied the *Item_Default_HoverPanel* display template.

+And gave it a new name: *TechNet_Content_HoverPanel.

+The following screenshot shows how these values are maintained for one item in our internal list.

+Again, because this isn't intuitive: *When adding custom properties to a hover panel, we have to add them to the item display template*.

+But, we aren't completely through yet. The values for *Internal Writer* and *Submission Contact* appeared differently. The screenshot might not show it clearly, but hopefully you can see that the value for *Internal Writer* appeared well, but the value for *Submission Contact* was long and contained an ugly GUID.

+And now the hover panel was starting to look good.

+But to make the hover panel even more helpful, we wanted to add an action to the bottom of the hover panel. will show how to do this.

+SharePoint Server uses several Windows encryption algorithms for computing hash values that don't comply with Federal Information Processing Standard (FIPS) 140-2, *Security Requirements for Cryptographic Modules*. These algorithms aren't used for security purposes; they're used for internal processing. For example, SharePoint Server uses MD5 to create hash values that are used as unique identifiers.

+Because SharePoint Server uses these algorithms, it doesn't support the Windows security policy setting that requires FIPS compliant algorithms for encryption and hashing. This Windows security policy is managed through the **FIPSAlgorithmPolicy** registry key in Windows, which is described in the "Configure FIPS policy for a mixed environment" section of the following article:

+The goal of FIPS is to provide a standardized way to ensure the security and privacy of sensitive information in computer systems of the United States and Canadian governments. Using a FIPS compliant algorithm for encryption of data over an open network is a key requirement for FISMA certification. The Windows FIPSAlgorithmPolicy registry key is not necessary or sufficient for FISMA certification, it's a useful enforcement tool for many solutions, but not SharePoint Server.

+For additional information about FISMA, see,[Federal Information Security Management Act (FISMA) Implementation Project.](https://go.microsoft.com/fwlink/?LinkId=242329)

+ Title: "Alternate access URLs haven't been configured (SharePoint Server)"

+description: "Learn how to resolve the SharePoint Health Analyzer rule: Alternate access URLs haven't been configured, for SharePoint Server."

+# Alternate access URLs haven't been configured (SharePoint Server)

+ **Rule Name:** Alternate access URLs haven't been configured.

+ **Summary:** A default zone URL must not point to the computer name of a front-end Web server. Because this installation has more than one front-end Web server, an incorrectly configured default zone URL can result in various errors, including incorrect links and failed operations.

+2. On the SharePoint Central Administration website home pages, in the System Settings section, click **Configure alternate access mappings**.

+ **Summary:** The database has large amounts of unused space allocated on the disk. This database uses a large amount of space on the file system unless it's shrunk down to a small size. This event occurs if the unused space is more than 20% of the disk space and the unused space is greater than the autogrowth size plus 50 megabytes (MB).

+- Normally you can safely ignore this event. You shrink a database only if it proves necessary ΓÇö for example, when you have performed an operation that removes a large quantity of data from a database, and the free space isn't expected to be used again. You can shrink the database by using the DBCC ShrinkDatabase command or SQL Server Management Studio. For more information, see [DBCC SHRINKDATABASE (Transact-SQL)](/sql/t-sql/database-console-commands/dbcc-shrinkdatabase-transact-sql) (https://go.microsoft.com/fwlink/p/?LinkID=110852) and [Shrink a Database](/sql/relational-databases/databases/shrink-a-database?viewFallbackFrom=sql-server-2014) (https://go.microsoft.com/fwlink/p/?LinkID=224904).

+ The white paper [Database maintenance for SharePoint](https://go.microsoft.com/fwlink/p/?LinkID=229104) provides important guidelines for shrinking a database. We strongly recommend that you read this white paper before you shrink a database.

+ Title: "Databases within this farm are set to read only and will fail to upgrade unless it's set to a read-write state (SharePoint Server)"

+description: "Learn how to resolve the SharePoint Health Analyzer rule: Databases within this farm are set to read only and will fail to upgrade unless it's set to a read-write state, for SharePoint Server."

+# Databases within this farm are set to read only and will fail to upgrade unless it's set to a read-write state (SharePoint Server)

+ **Rule Name:** Databases within this farm are set to read only and will fail to upgrade unless it's set to a read-write state.

+ **Summary:** The databases are set to read-only and can't be upgraded.

+ **Summary:** This health rule checks to see if the multiple app domains feature is enabled by looking at the state of the _Microsoft.SharePoint.Administration.SPWebService.ContentService.SupportMultipleAppDomains_ property. If this is enabled, the health rule then checks to see if there are multiple web application zones in each web application. If there are, it continues to check if there's an app domain defined for each web application zone. The health rule alert is triggered if the final condition isn't met. It's also triggered if the web application and app domain aren't using the same Internet Information Services (IIS) port binding, web application zone, application pool account, and authentication type.

+ **Cause:** The SharePoint Server environment isn't set to use multiple app domains, or the web application is incorrectly configured for multiple web application zones.

+description: "Learn how to resolve the SharePoint Health Analyzer rule: eOne or more services have started or stopped unexpectedly, for SharePoint Server."

+ **Summary:** A critical service required for the SharePoint farm to function isn't running.

+ **Cause:** One or more critical services aren't running on the specified server.

+2. In Server Manager, select **Tools**, and then select **Services**.

+3. Right-click the service that you want to start, and then select **Start**.

+ Title: "Outbound e-mail hasn't been configured (SharePoint Server)"

+description: "Learn how to resolve the SharePoint Health Analyzer rule: Outbound email hasn't been configured, for SharePoint Server."

+# Outbound e-mail hasn't been configured (SharePoint Server)

+ **Rule Name:** Outbound email hasn't been configured.

+ **Summary:** An outgoing email server hasn't been configured on this SharePoint Server deployment. With no SMPT server configured for outgoing email, SharePoint Server can't send email messages, including alert email, confirmation email, invitation email, and email about exceeding quotas.

+2. On the SharePoint Central Administration website, select **System Settings**.

+3. On the System Settings page, in the **E-Mail and Text Messages (SMS)** section, select **Configure outgoing e-mail settings**.

+5. Select **OK**.

+### Concepts

+description: "Learn how to resolve the SharePoint Health Analyzer rule: People Search relevance isn't optimized when the Active Directory has errors in the manager reporting structure, for SharePoint Server."

+ **Rule Name:** People Search relevance isn't optimized when the Active Directory has errors in the manager reporting structure.

+ **Cause:** Company leaders haven't been explicitly specified.

+ - Administrators group on the server on which you're running the Microsoft PowerShell cmdlets.

+ > If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For more information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps&preserve-view=true).

+ where *\<Domain\UserName\>* is the user account that you want to add as a leaderΓÇöfor example, Contoso\Joe.Healy. For more information, see [Add-SPProfileLeader](/powershell/module/sharepoint-server/Add-SPProfileLeader?view=sharepoint-ps&preserve-view=true).

+5. You're prompted to confirm. Type **Y** to confirm.

+description: "Learn how to resolve the SharePoint Health Analyzer rule: Product / patch installation or server upgrade required for SharePoint Server."

+ **Rule Name:** Product / patch installation or server upgrade required.

+ **Cause:** You haven't installed required products or updates, or the server needs to be upgraded.

+If a previous upgrade attempt has failed, you must resolve upgrade issues before attempting upgrade again. You can use the SharePoint Central Administration website to find information about current and previous upgrade attempts and determine issues that may be preventing upgrade from succeeding. To do this in Central Administration, in the **Upgrade and Migration** section, select **Check upgrade status**.

+ **Rule Name:** The Security Token Service isn't available.

+ **Summary:** The Security Token Service isn't issuing tokens.

+2. Identify the server on which this event occurs. On the SharePoint Central Administration website, in the **Monitoring** section, select **Review problems and solutions**, and then find the name of the server in the **Failing Servers** column. If there are multiple failing servers in a server farm, you must repeat the following steps on each failing server.

+5. Open **Server Manager,** select **Tools**, and then select **Internet Information Services (IIS) Manager**.

+6. In the Internet Information Services management console, in the **Connections** pane, expand the tree view, and then select **Application Pools**.

+7. In the **Application Pools** list, right-click **SecurityTokenServiceApplicationPool**, and then select **Start**. If the application pool is started already, select **Stop** and then, in the **Action** pane, select **Start** to restart it.

+ Confirm whether the STS certificate has expired by looking for Windows Application event log Event ID 8311 for source "SharePoint Foundation," category Topology, and with "NotTimeValid" in the message. This indicates an expired STS certificate. For more information on updating the STS certificate, please see [Replace the STS certificate for SharePoint Server](/SharePoint/administration/replace-the-sts-certificate).

+description: "Learn how to resolve the SharePoint Health Analyzer rule: Verify that the critical User Profile Application and User Profile Proxy Application timer jobs are available and haven't been mistakenly deleted, for SharePoint Server."

+ **Rule Name:** Verify that the critical User Profile Application and User Profile Proxy Application timer jobs are available and haven't been mistakenly deleted.

+ **Summary:** User Profile Service Application or User Profile service proxy timer jobs aren't available and might have been deleted.

+1. On the SharePoint Central Administration website, select **Monitoring**.

+2. On the Monitoring page, in the **Health Analyzer** section, select **Review rule definitions**.

+3. On the Health Analyzer Rule Definitions - All Rules page, in the **Category: Configuration** section, select the name of the rule.

+4. In the **Health Analyzer Rule Definitions** dialog, select **Edit Item**.

+5. Select the **Repair Automatically** check box, and then select **Save**.

+description: "Learn how to use Windows PowerShell scripts to help cleaning up SharePoint Server 2016 databases after a successful upgrade procedure."

+For a list of the sample scripts to use, see [Post-upgrade scripts.](https://gallery.technet.microsoft.com/sharepoint/Post-Upgrade-Cleanup-35099a7a)

+For more information on how to handle cleanup of a database, see [Post Upgrade Cleanup - Missing Server Side Dependencies.](/archive/blogs/dawiese/post-upgrade-cleanup-missing-server-side-dependencies)